TEAM Zarate Tarrani Notes From the Field

Buying Software and Other Frightening Acts. Recent entries in Postcards from the Revolution we're discussing software RFPs and related topics. It all boils down to the same issues and factors, regardless of what you're buying - a house, car, landscaping. You want the best possible product or service at the best possible price. The seller wants your business and to make a profit. At issue is quality, and in the case of software quality encompasses a number of attributes:

• Works in your environment without requiring upgrades, modifications to your equipment or processes and does not impose a maintenance burden.
• Contains the features and functions you specified.
• Is free of defects.

Bug or Feature?. Of course, the list of attributes is longer, but these are the major ones.

Let's focus on the last: free of defects. There used to be a facetious saying, It's not a bug, it's a feature. In real life, if requirements and specifications are poorly written the definition of defect may be open to argument. I like Cem Kaner's article titled, What is a Software Defect? because he clearly defines what a defect is, and as importantly, what a defect is not. Mr. Kaner is a well known software quality professional and an attorney, so a prudent person would consider his definition as at least a starting point.

Caveat Emptor. Testing, especially acceptance testing, is the responsibility of the customer. This holds true whether you're buying a car or outsourcing software development. Therefore, before a contract is signed there has to be agreement between both parties as to what constitutes quality and non-quality, how defects are to be handled when your acceptance test detects them, and a plethora of related issues that are beyond the scope of this entry.

One of the goals of acceptance testing is to make sure that the features and functions you specified are actually included in the software and they operate consistently with what you specified. My preferred method for specifying requirements is through business rules. I've covered this method in reasonable detail in Postcards from the Revolution, so I'll only mention them here. However, there are other methods that may be a better fit to your organization's processes and procedures for requirements management. One article that shows viable alternatives is Requirements that Handle IKIWISI, COTS and Rapid Change by Dr. Barry Boehm. IKIWISI stands for I know it when I see it (a common phenomena encountered by requirements analysts and facilitators), and COTS is commercial off-the-shelf software.

If you are contracting for software development with a vendor that employs object-oriented methods (or are developing in-house using them), you may want to read Business Rules and Object Role Modeling, which aligns the business rules approach to object-oriented methods.

It's About PM. There is more to outsourced or in-house software development than requirements, specifications and acceptance testing - there is an entire life cycle that needs to be managed. While there are distinct issues that need to be addressed when the project is outsourced, there are common issues shared by outsourced and in-house development. I've put together a Zip archive that contains three short PowerPoint presentations that cover the project management basics as a PM briefing. In addition, the PowerPoint presentation titled Nature of IT projects will prove useful, especially the facts cited in the form of quick quizzes.

You may also want to get a copy of the 1996 version of the Project Management Body of Knowledge (the 2000 version is not available as a complete document in the free version). Don't forget that properly closing out projects is as important as the initiation and management processes. You'll find valuable advice in the MS Word document titled Project Post Mortems. This connects nicely with Kate's work supporting knowledge capture.

Loose Ends. Wrapping this entry up are three documents that relate to what I've covered above:

1. Cost-Benefit Analysis of Test Automation. At some point it's going to make good business sense to invest in test automation tools. This paper will help you to determine when is the optimum time to make the investment and expected ROI. Don't forget to have a process in place before spending money on tools!
2. Familiar Metric Management - Effort, Development Time, and Defects Interact, which seamlessly ties together project and testing metrics.
3. Customer Negotiation Metrics - 17 PowerPoint slides you should read before sitting down with your vendor.