May 8, 2006

"RUPTURED STALKTHRUS - WHY REVIEWS ARE IMPORTANT"

Back in the late 1970's and early 1980's when the Structured Programming movement was in full swing, there was an emphasis on "Structured Walkthrus" whereby a programmer and a team of his peers would review the source code for maintainability and design correctness. Unfortunately, the code was often cluttered and complicated making such reviews cumbersome and led to the phrase "Ruptured Stalkthrus." Today, code reviews are rarely performed, but this leads me to discuss the importance of reviews in general.

Conducting reviews is an essential part of any effective systems development project. Some application developers believe it has an adverse effect on project delivery schedules and, as such, avoids reviews at all costs. This, of course, is absurd. The development of any system or major software project involves many people and, as such, communications and consensus are vital for tackling complex projects.

For additional information, see:

No. 52 - "Understanding the Vicious Circle of Complexity" - Nov 28, 2005

In addition to communications, reviews promote cooperation and trust between the parties involved, but more importantly they are intended to assure developers are building the right product for the right business problem. "Design correctness" is the primary purpose of any review in application development which, of course, is an important part of an overall quality assurance program. Reviews are not intended to criticize the developers but rather to make some important business decisions during a project, such as: accept the design as proposed, modify or correct the design before proceeding, or to cease development.

Periodically stopping and reviewing designs benefits both developers and end-users alike (the clients). For the developer, a second set of eyes is invaluable; to illustrate, being imbued in a development project, problems and errors can become transparent to the developer and are sometimes overlooked. By having others review your work, they may have little trouble in spotting such errors or recommending alternatives. In other words, reviews should not be avoided, but rather welcomed by the developer. For the end-users, reviews are necessary to assure their interests are being represented, that the system and software satisfies their needs. Frequently, end-users abdicate attendance at design reviews because they are often fraught with technical gobbledygook that alienates the user. However, if project reviews are presented in a standard and consistent manner, avoiding technical jargon, users are more apt to attend. Further, having a standard evaluation/acceptance criteria (such as in the form of review checklists) can greatly facilitate the review process for both developers and end-users. Bottom-line, reviews are intended for people to reach consensus as to the proper direction for a development project.

CONDUCTING THE REVIEW MEETING

"Free-for-all" reviews are pointless and tends to alienate all involved. Instead, reviews should be structured and well organized thereby maximizing the use of time for all involved. Here are some tips for conducting an effective review meeting:

• Meeting should be conducted by the Project Manager. Participants should include assigned developers, end-users, quality assurance personnel, and perhaps development management (depending on the type of review).

• Schedule the meeting for a time and place convenient to all.

• Have a printed agenda for the meeting describing its purpose, and highlighting the points to be discussed. Start the meeting on time and get to the point, do not ramble.

• Provide the design documents (deliverables) to the participants prior to the meeting. Allow them ample time to study it and formulate questions prior to the review. Ideally, deliverables should be well organized and packaged, complete with a table of contents and a review checklist. Depending on the level of detail involved, technical jargon should be avoided and presented in a form that all will understand.

• If the deliverable is accepted, have all participants sign a master copy of it thereby denoting they have reviewed and approved it. I cannot stress the need for signatures strong enough; they represent commitments.

WHEN SHOULD REVIEW MEETINGS BE CONDUCTED?

At the beginning of a project or at the end? Neither. Review meetings should be held throughout the life of the project at specific stages of development. By doing so we accomplish two things: we are inspecting quality into the product during design (not checking for it afterwards), and we are can confirm we are building the right product according to specifications thereby assuring customer satisfaction.

Let me give you an example of incremental reviews using our "PRIDE"-Information Systems Engineering Methodology (ISEM).

Please keep in mind "PRIDE"-ISEM considers a system to be a product that can be engineered and manufactured like any other product. Consequently, it has different levels of abstraction in the system hierarchy and, as such, has different deliverables to specify each level (this is sometimes referred to as "stepwise refinement"). The hierarchy of the "PRIDE" System Structure consists of:

Level I: System
Level II: Sub-Systems (aka Business Processes)
Level III: Procedures (both manual and computer)
Level IV: Steps for manual procedures and Programs for computer procedures.

The early phases of "PRIDE"-ISEM are used to design the system top-down and the latter phases are used to test and install the system bottom-up. Here is how it works...

PHASE 1 - SYSTEM STUDY & EVALUATION

Deliverable - "System Study & Evaluation Report" (Feasibility Study).

What is specified - Information Requirements and preliminary design of the system (rough), from which project estimates and schedules can be formulated and a cost/benefit analysis developed.

Who performs the work - primarily Systems Engineers.

Who participates in the review - Project Management, Systems Engineers, Software Engineers, Quality Assurance, User Management, and Development Management.

What is reviewed - Primarily the Information Requirements for clarity and correctness, the proposed System Solution (its viability), and the project plan (costs and schedules).

PHASE 2 - SYSTEM DESIGN

Deliverable - "System Design Manual."

What is specified - Sub-Systems (aka Business Processes), Inputs, Outputs, and the application's logical data base (representing the interface between sub-systems).

Who performs the work - Systems Engineers.

Who participates in the review - Project Management, Systems Engineers, Quality Assurance, User Management, and Development Management.

What is reviewed - The viability of the sub-systems, illustrative examples of inputs and outputs, and a review of the updated project plan.

PHASE 3 - SUB-SYSTEM DESIGN

Deliverable - "Sub-System Design Manual."

What is specified - Procedures (the procedural workflow of the business process), Inputs and Outputs are finalized, primary and temporary physical files, and a review of the updated project plan (as it pertains to the individual sub-system).

Who performs the work - Systems Engineers.

Who participates in the review - Project Management, Systems Engineers, Software Engineers, Quality Assurance, Operation Management, and User Management.

What is reviewed - The viability of the procedures and the "look and feel" of the inputs and outputs.

PHASE 4-I - ADMINISTRATIVE PROCEDURE DESIGN

Deliverable - "Administrative Procedures Manual" (aka User Manual).

What is specified - Operational Steps (tasks) of the Administrative (Manual) Procedures.

Who performs the work - Systems Engineers.

Who participates in the review - Project Management, Systems Engineers, Quality Assurance, User Management.

What is reviewed - The viability of the steps in the procedures.

PHASE 4-II - SOFTWARE ENGINEERING

Deliverable - "Computer Run Book."

What is specified - Programs in the Computer Procedure.

Who performs the work - Software Engineers.

Who participates in the review - Project Management, System Engineers, Software Engineers, Quality Assurance, Operations Management.

What is reviewed - The viability of the program(s) design and the completeness of program specifications.

PHASE 5 - SOFTWARE MANUFACTURING

Deliverable - Object/Source Code & Test Results.

Who performs the work - Software Engineering

Who participates in the review - Project Management, Software Engineers, and Quality Assurance.

What is reviewed - Test results (for a single program). However, if source code is produced using traditional manual coding techniques, code reviews are appropriate (this is normally not necessary for code produced using devices such as a program generator).

PHASE 6 - SOFTWARE TESTING

Deliverable - Test Results.

Who performs the work - Software Engineers.

Who participates in the review - Project Management, Software Engineers, Systems Engineers, Quality Assurance, and Operations Management.

What is reviewed - Test results (of all programs in the computer procedure).

PHASE 7 - SUB-SYSTEM TESTING

Deliverable - Test Results.

Who performs the work - System Engineers.

Who participates in the review - Project Management, Systems Engineers, Software Engineers, Quality Assurance, User Management, and Operations Management.

What is reviewed - Test results (of all procedures in the sub-system).

PHASE 8 - SYSTEM OPERATION

Deliverable - Test Results.

Who performs the work - System Engineers.

Who participates in the review - Project Management, Systems Engineers, Software Engineers, Quality Assurance, User Management, and Operations Management.

What is reviewed - Test results (of all sub-systems in the system).

PHASE 9 - ISEM EVALUATION

Deliverable - System Audit.

Who performs the work - Project Management and Systems Engineers.

Who participates in the review - Project Management, Systems Engineers, Quality Assurance, User Management, and Development Management.

What is reviewed - How well the system satisfies requirements and a project evaluation (estimated vs. actual costs and schedules).

CONCLUSION

Of course we have similar review points in our "PRIDE"-Enterprise Engineering Methodology (EEM) and "PRIDE"-Data Base Engineering Methodology (DBEM). However, this bulletin is primarily concerned with the systems development process.

Because of the complexity of systems, certain tools should be used to assist in the review process. For example, Review Checklists should be devised for evaluating deliverables. Such checklists represent the standard acceptance criteria of each deliverable. Another useful tool is an IRM Repository (aka Dictionary) for cataloging and controlling information resources. Such tools are invaluable for substantiating completeness of designs. Down in the programming phases, certain software testing/debugging aids are useful for diagnosing problems in a program. The use of such tools should be encouraged to promote confidence in the integrity of designs.

As mentioned earlier, systems can be complex in terms of the number of information resources involved and the people participating in the project. Consequently, reviews are essential to assure that the product being produced conforms to its specifications; that problems can be spotted and corrected early on as opposed to afterwards. Reviews at the beginning and end of a project are nice, but incremental reviews are necessary for quality assurance and customer satisfaction purposes. In this way, we can avoid "Ruptured Stalkthrus" and deliver a quality product to the customer.

OUR BRYCE'S LAW OF THE WEEK therefore is...
"Quality must be built into the product during design, not inspected in afterwards."

FRAPPER MAP

Friends, I don't know if you've seen it yet, but we've added a Frapper map to the "Management Visions" web site. Frapper is a free mapping service offered by the folks at Rising Concepts, LLC, and allows you to plot yourself on a worldwide map. This is a great way to keep track of our listeners and I encourage you to try it out through our web page or by clicking HERE.

IN OUR "DOWN THE ROAD" SECTION

The 17th International Conference of the Information Resource Management Association will be held May 21st-24th at the Wyndham Hotel in Washington D.C. For information, call IRMA headquarters in PA at 717/533-8879

The National And State CIO Association will be holding their 2006 Midyear Conference at The Capital Hilton, in Washington, DC on May 31st-June 2nd. For information, contact NASCIO headquarters in Lexington, KY at: 859/514-9153

MIT's Center for Information Systems Research will hold its annual conference from June 12-16, 2006 on the MIT campus. For information, contact MIT at 617/253-2348

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@phmainstreet.com

MY "PET PEEVE OF THE WEEK" IS "NETWORKING" (or the lack thereof)

I've been bumping into a lot of younger people lately; young men in their early to mid-20's who have been asking me for advice on a variety of issues as they begin their careers. Basically, I tell them to start a life insurance policy, write a will, how to dress, and basic social amenities such as how to greet someone and tell a joke. More importantly I stress upon them the need to network with their contemporaries.

When I was entering the work force back in the 1970's I found networking to be invaluable in my professional growth. I was particularly active in trade related organizations such as the local chapters of the Association for Systems Management, the Data Processing Management Association, and the Association for Computing Machinery. I also founded a local OS/2 Users Group and Java Users Group. I have also participated in other civic and fraternal organizations. All of these groups were invaluable to me in terms of education and the development of a network of contacts from whom I have relied on time and again.

I've noticed the younger people are less inclined to join in any such organization these days. I'm not sure why. Perhaps they don't think its cool. Perhaps there is no professional curiosity. Or perhaps they just don't know any better. Frankly, I think its the latter. As a result, these organizations are in decline. For example, ASM is now extinct; and DPMA changed its name and focus to the Association of IT Professionals; regardless their numbers are still diminishing. Instead of resisting participation in such organizations, I encourage young people to join them.

Networking is a great way to learn about your field of interest and to develop local contacts who might be helpful to you in your walk through life and you might be able to help them in return. Many people go into such organizations with the wrong intentions, such as they are going to sell the membership something. This is most definitely not the point; its about your professional growth. Its about learning; its about refining your social skills, and its about gaining visibility; all of which is important for developing a professional reputation. Once this is established, people will recognize you as the "go to" guy in your area of specialty, then, Yes, you may vary well get some business. But don't go into an organization thinking you're going to conquer the world, think of it as an investment in your personal development.

One of the lessons I learned during my college career was that "We enjoy life through the help and society of others." I have found this to be particularly true in my professional development.

So, instead of staying home and watching that crap on TV every night, how about getting of your ass and attend a couple of meetings? Start with a trade group from your industry; then there's the chamber of commerce and Jaycees; then there's volunteer organizations such as the Rotary, Kiwanis and the Lions; then there's fraternal organizations such as the Masons and the Shrine. The list is actually endless; but seek out those organizations that will help you the most in your professional development. You might learn a thing or two in the process, and others might just learn a thing or two about you.

Such is my Pet Peeve of the Week.

AND FINALLY...

I received an e-mail from an AC Kemper in Ohio who writes...
AC writes:

"I enjoy your "PRIDE" Methodologies for IRM as displayed on the web, but don't you have an abridged version in book format?"

Thanks AC for your note,
Funny you should mention it, but we are currently working on a new eBook version of the methodologies as well as an Audio Book version which will be useful for people on the run. You can expect some announcements from us very soon.

Again, Thanks for your e-mail. Keep those cards and letters coming.

Folks, don't forget to check out our BRYCE'S CRASH COURSE IN MANAGEMENT which is a free on-line multimedia presentation offering pragmatic advice on how to discharge the duties of a manager, whether it be for a commercial or non-profit enterprise. Frankly, for someone aspiring to be a manager or for a new manager, it will be the best 45 minutes you can invest in yourself. Check it out on the cover of our corporate web page at: http://www.phmainstreet.com/mba

For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END