Vendor management

7.3 Vendor management

Purchasing software is often risky business at best. While there are many reasons for an organization to buy software rather than write it in-house, the role of the software quality practitioner often is reduced. Thus, the risks increase that the software will not meet its requirements.

When software is purchased, much, if not all, control over development is lost. The risks run from slightly more than those for in-house development all the way to what-you-see-is-what-you-get (WYSIWYG). The role of the software quality practitioner changes when software is purchased. Since visibility into the development process is diminished, if not lost altogether, other avenues must be found to investigate and ascertain software quality. The software quality practitioner must be innovative in selecting quality methods to apply and firm in insisting that those methods are applied. There are many packages and methodologies that can help with software product acquisition, but the basic quality concerns remain the same.

Three basic types of software purchase are available: off-the-shelf, tailored, and new development. Each type presents a different challenge to the software quality practitioner. Visibility and influence over the development process change as each type of purchase is exercised. Table 7.2 presents examples of purchased software and the quality approaches that could be applied to them.

Table 7.2: Purchased Software Quality Approaches

Type

Source

Quality Approach

Graphics application

Off the shelf

Vendor reputation

  

Trial-use period

Database manager

Off the shelf

Vendor reputation

  

Trial-use period

Operating system

Vendor

Trial-use period

  

Vendor maintenance

Tailored application

Application customizer

Partial purchaser SQS

  

Test records

  

Vendor maintenance

Contracted application

Third-party developer

Full purchaser SQS

  

Vendor maintenance

 

Off-shore developer

Full purchaser SQS

  

On-site inspection

  

Vendor maintenance

Each type of purchase presents different maintenance situations. Who will maintain the purchased software is an important consideration for the software quality practitioner in evaluating purchased software.

7.3.1 Off-the-shelf software

Purchasing off-the-shelf software allows little or no insight into the processes involved in its development.

Software purchased off-the-shelf, such as an operating system, a compiler, or database management system, whether for a mainframe or a portable computer, usually comes as-is. Usually, there are no guarantees and sometimes there are blunt denials of any liability on the part of the vendor. This type of software offers the greatest challenge to software quality practitioners.

Few traditional quality assurance steps can be taken with off-the-shelf software. Often, the only evidence of a vendor's software development process is its reputation and, in some cases, life span, in the marketplace. The quality and availability of documentation can also provide clues. However, even in the best of cases, visibility into the development process is dim and unreliable. Software quality practitioners must resort to emphasis on other aspects of software development in order to do their job.

The primary step is to clearly identify the requirements for a software package that is needed. Software quality practitioners must make every effort to determine what the organizational needs are for a software purchase. For example, many database packages exist for personal computers. If a company or organization decided to provide its employees with PC workstations, including a database package, software quality practitioners must urge as much specificity in the requirements of the database as can be determined. Once the actual, intended use and application of the database package are determined, evaluation of candidate vendors and their products can commence. It is no different from traditional software development at this point. Until the software requirements are known, software development, or in this case purchase, should not begin.

Having settled on the requirements, vendor and product evaluation can begin. Vendors with the reputation of developing sound packages and packages that best appear to meet the requirements will be identified. When one or more possible packages have been identified, two more SQS activities that should take place: the specific testing of the packages and consideration of future maintenance. Either or both of these actions may be impossible for a given vendor or product. In that case, that product should be dismissed.

The vendor should provide for a period of real-world use of a potential package. Most acceptable vendors will allow a trial-use period in which the buyer has a chance to see if the product really meets the requirements for it. Unless there are serious, overriding conditions, software quality practitioners should counsel against purchase of off-the-shelf software from a vendor that will not allow such a test. Test or demonstration portions of many packages are also available for trial use. Some vendors sell the demonstration package and give credit for the demonstration package price against the purchase of the full software package. It should be noted that demonstrations may gloss over or skip potentially troublesome characteristics or weaknesses.

When permitted by licensing terms or provisions, reverse-engineering techniques can be applied to establish design methods or data models. These can then be assessed for compliance to the approved requirements. Such techniques must only be undertaken when the vendor grants permission. The quality practitioner should alert management that such activities may result in legal action on the part of the vendor for copyright infringement.

The second action is the review of vendor software maintenance provisions. A package that provides for vendor support, free updates when latent defects are found and corrected, reduced cost for new versions offering enhanced capability, and the like, should receive special attention. Vendors that agree to nothing, once the package has been bought, should be viewed with a suspicious eye by software quality practitioners. The most likely case is a negotiated agreement as to the costs involved in various kinds of maintenance situations. Again, the vendor's marketplace reputation should influence this activity.

All in all, purchase of off-the-shelf packages is risk intensive. Of course, there are situations when it is the proper method of providing software capability to users. Software quality practitioners must recognize the risks involved, however, and act to reduce those risks with whatever means are available. One rule of thumb might be if you can't try it, don't buy it, and if they won't fix it, deep six it.

7.3.2 Customized shells

Software can often be purchased as a shell, which is generic and off-the-shelf. Its advantage is that the purchaser's unique needs are then custom built into the shell and the total package tailored to the specific application.

As in pure off-the-shelf software, software quality practitioners will have little influence over the generic shell portion. These shells are usually pre-built and act as a foundation for the customized software to be added. Software quality practitioners should encourage negotiation of development control over the customized portions.

The reputation of the vendor often is a good clue in this type of software purchase, just as it is for off-the-shelf software. During early evaluation of potential vendors and shells, software quality practitioners can review marketplace reports to help identify leading vendors for particular applications.

After-purchase maintenance also must be considered. Unlike most off-the-shelf software, a purchaser may be able to take over some or all of the maintenance of a tailored package. Cost of source documentation for the shell, postpurchase vendor maintenance announcements, and the buyer's ability to maintain the software should be investigated by software quality practitioners and corresponding recommendations made to management.

It is entirely acceptable to request that the vendor's proprietary source code be placed in escrow against the possibility that the vendor becomes unwilling or unable to continue maintenance of the software. In such an event, the customer would receive the code from the escrow and take over maintenance at that point. In some cases, the source code would become the property of the customer after some contractually agreed period of time has passed. In that way, the vendor's proprietary property is protected, and the customer is at less risk of loss of maintainability of important software. It is also important to have the right to ensure that the source code in escrow does, in fact, match the object code being run.

Testing of the custom portion of the software is commonplace, so the software quality practitioner's main concerns in this area are the quality of the software requirements and the adequacy of the test program. Software quality practitioners must urge the preparation of an adequate statement of requirements for the software and then ascertain that the test program will, while finding defects, give confidence that the software meets the requirements.

Finally, software quality practitioners should encourage management to secure warrantees or guarantees with respect to at least the custom portions of the software.

7.3.3 Contracted new development

Purchase of total software packages, developed as new software for a specific buyer, provides the greatest opportunity for involvement of the purchaser's software quality practitioners.

The purchase of, or contract for the development of, a new software package is similar to an in-house development effort. All the same activities in the software development process must be accomplished under the auspices of the software quality practitioners. It is expected that the buyer's software quality requirements will cause the invocation of at least as stringent software quality requirements on the vendor as are followed by the buyer. Even when more strict software quality requirements are placed on the vendor, the buyer's software quality practitioner's visibility is probably hampered.

Remembering that the purchase of new software permits (in fact, requires) the buyer to specify all of the software requirements, the software quality practitioner should be certain to have all of its quality program requirements included in the contract. Not only should the vendor be contractually required to provide a strong software quality program, the buyer's software quality requirements must demand visibility into that program and its conduct. The buyer must have the right to conduct regularly scheduled and unscheduled reviews and audits of the vendor's development process and controls at the vendor's facility. Too often, these reviews and audits are held at the buyer's facility and amount to little more than dog and pony shows at which the buyer is assured that everything is fine. Only later does the buyer discover that costs are overrun, schedules have slipped, and the software does not work. The buyer's software quality practitioners must be provided the contractual right to visibility into the vendor's activities.

Maintenance of the software continues to be a concern of software quality practitioners. If the vendor will be contracted to maintain the software, software quality practitioners should continue their regular level of visibility into the vendor's processes. When maintenance becomes the responsibility of the buyer, software quality practitioners must be sure that training, documentation, and the in-house facility to maintain the software are in place prior to delivery of the new software.

Finally, software quality practitioners should be sure that all new software being purchased is subject to rigorous, requirements-based acceptance testing prior to approval and acceptance by the buyer.

7.3.4 Remote development

More and more development is becoming a remote activity. Beginning as off-shore coding vendors, many companies in so-called developing countries were formed to receive detailed design specifications from software developers and deliver the source code for them. It became apparent that some of these off-shore companies were also ready, willing, and able to provide detailed design specifications from architectural design. Now, some of the companies are doing all the design and coding based on received requirements specifications.

Naturally, the remoteness of the work being performed was, is, and continues to be a problem for coordination and oversight. Various techniques and approaches to this situation are being used. Certainly, very close review of the products as they are received is a necessity. Vigorous and rigorous testing is also demanded.

Even closer coordination techniques include regular on-site visits to the suppliers to establishing offices in the suppliers' locations.

The economies of lower labor costs and higher productivity can be negatively affected by poor quality products from remote suppliers. Software quality practitioners need to take an aggressive role in reviewing and testing remotely developed products.

7.3.5 Vendor management wrap-up

All purchased software carries risks not present in software developed in-house. Software quality practitioners must be innovative in both identifying the various risks associated with the different types of software purchase and finding ways to meet and blunt those risks.

Software quality practitioners must be aware not only of the developmental risks but also of the maintenance requirements for the software after delivery. Maintenance training, suitable maintenance-oriented documentation, and the hardware and software facilities to support software maintenance must be available. Placing the vendor's proprietary source code in escrow should also be considered. Software quality practitioners are responsible for ascertaining the availability and sufficiency of software maintenance needs. If anything is lacking in this area, software quality practitioners need to make management aware of those issues.



Practical Guide to Software Quality Management
Practical Guide to Software Quality Management (Artech House Computing Library)
ISBN: 1580535275
EAN: 2147483647
Year: 2002
Pages: 137
Authors: John W. Horch

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net