This project is read-only.

Chapter 16 - Legal perspective

The decision to accept software is often governed by terms in a legally binding contract. The acceptance decision may therefore have legal ramifications which may override considerations related to functional and non-functional acceptance criteria.

Note:
Disclaimer: This chapter is not meant to be used as legal advice. Since acceptance is a major legal milestone of commercial software system development, it is important to keep in mind the following:

Acceptance May Have Legal Ramifications

As part of the contractual process, acceptance typically results in rendering a payment as well as it affects the application of any warranty provisions and potentially any remedies available to the customer. When defining the contract, make sure that the appropriate factors are taken into consideration. The relationship between the acceptance of the product into a production environment and the contractual acceptance of the product as “complete” should be clearly spelled out.
Acceptance can be approached from two positions: explicit provisions specified in the software development contract and the terms implied into the contract by law (which also depends on the geographic jurisdiction). Implicit provisions may also differ based on whether the software is rendered as a product or as a service. To see what provisions (explicit and implicit) do apply to your case, consult your legal counselor.

Contract Should Stipulate Acceptance Process

When software development is outsourced, the contract should clearly stipulate the acceptance process and how the acceptance criteria will be determined. It is important to also specify any expectations about how much readiness assessment will be conducted by the supplier and how the criteria for readiness assessment will be determined. For example, will the customer be providing the supplier with the acceptance tests, a representative sample of the acceptance tests or leaving the supplier to determine what tests to run (the “Battleship ™ approach”.)
The contract should not just stipulate when the supplier must deliver the system but also how long the customer can take for acceptance testing. Acceptance testing is usually time-boxed. The customer is given so much time to accept software and report deficiencies, after which the software is deemed complete if there are no “show stopper” bugs. The contract must stipulate the criteria used to determine whether a bug is indeed a “show stopper” or “gating” bug.
The contract should also stipulate where the different steps of the acceptance process will be carried out. In case of custom build software system, preliminary acceptance testing may be performed at the location of supplier, while final acceptance testing (both functional and operational) is performed when the software is deployed to the customer. The contract may stipulate that, as part of the acceptance procedure, the software system be successfully run with current data in a live operating environment for a period of time, with minimum bugs, before the system is contractually accepted.
The contract should not be one-sided; it should encourage both parties to get to a mutually agreeable acceptance as quickly as possible. Contracts that penalize one party often lead to dysfunctional behavior that results in lose-lose outcomes.

Last edited Nov 5, 2009 at 11:46 PM by rburte, version 1

Comments

No comments yet.