2.3. Software contracting
Bainbridge (2000) indicates the areas of law that are central for the professionals active in software contracting. These are the intellectual property (copyright, patents, the law of confidence[1] and trade marks), contract, criminal law and data protection law. When scrutinizing the list the richness and diversity of what is needed to be well equipped in a software contracting situation can be seen. The software contracting process starts seriously when the tentative procurement process from the customer’s side and the selling process from the supplier’s side are successfully matched. He emphasizes the importance of a “balanced, fair and thorough negotiation is the key to a smooth-running contract and all the relevant contractual terms and mechanisms should be considered and agreed before the parties become committed to the contract” (ibid, 164).
The software contracting process has not been addressed directly from the perspective described in this study in the earlier software contracting literature. Some papers discuss the problem from the following particular points of view: Whang (1992) has treated the contracting for software development extensively from a mathematical and game theoretical point of view. Shavell (1984) has examined contracting in general and also using only mathematical methods in his study. They both introduce mathematical models that are highly theoretical and hard to apply in practice with their many constraints. Still they give ideas about the matters to be taken in consideration when building a more practical contracting process model.
Marciniak and Reifer (1990) have described one of the first published software contract models. However, this model depicts only the initial stages of the whole software contracting and development process, besides it emphasizes the procurer’s view. Fig. 8 highlights the domains that are under scrutiny in this study. The procurer solely normally carries out the parts indicated by double line. Even though the study of the contract negotiation is completed from the supplier’s side there is always two parties present. For the supplier it is valuable to know and understand the customer’s intentions and behaviour in the negotiation situation.
Software contracts can be in broad terms divided into main categories that are the sale contracts and the licence agreements. This is due to the prevailing software business practices: sale contract is used for tailored and MOTS software development and sale and license agreement is used again in COTS and MOTS software business environment. In the subsequent analysis the classification from Bainbridge (2000, 207) is followed. Griffel et al. (1998) discusses the generic model of contracting fitted in an Internet environment using special contracting software. They define three main phases for contracting: information phase, negotiations phase and execution phase. ”A contract represents gathered information, agreed terms and conditions and steps to fulfil mutual commitments in a formal way, combined into one structured document”.
Kilde (1999) gives five central elements in software contracting and cooperation see Fig. 9:
Visualization; the goal, the process and the method of implementation is well described,
Selection of the cooperation form; i.e. integrated and defined project cooperation between the customer and supplier with a conflict handling procedures,
Managing the uncertainty; customer and supplier identify general and specific uncertainty elements and agree how these will be handled,
Incentives and sanctions; customer and supplier construct a price structure that reflects the division of uncertainty in order to specify the economic consequences (positive or negative).
Change management; customer and supplier estimate and evaluate the changes as planned in connection to the next iteration round.
Fig. 9 shows the central position of contracts in the context of a software producing company. The contract affects and touches all parts and functions of the company. Kilde (1998, 1999) has proposed an interesting model for software development also including parts of a contracting processes. The model has been constructed under the Norwegian University of Science and Technology (NTNU) project "Prosjektstyring år 2000" based on the participating organizations experiences.
Figure 9. Project management"s central domains and the contract"s role in context of software company (Kilde 1998, 17).
Thus it has its origins in practice. This model showed in Fig. 10 is intended for software projects for tailored and MOTS type of software development processes. In these modes there are the software reuse and implementing of components (MOTS) and on the other hand the production of software according to the customer’s specifications and the delivery of them in functional entities or increments (tailored).
The model constitutes four main phases that always end in a main milestone that is indicated by MMS 0 through MMS 3 in Fig. 10:
MMS 0: Before the contract is signed at this milestone it is preceded by the definition of needs phase where the prioritising of the requirements and needs, analysis of factors of uncertainty is completed and documented, development tools and environment is selected and overall implementation plan is drafted.
Next the actual development work is carried out under the solution description and the Iterative construction phases:
MMS 1: This milestone is preceded by the solution description phase where the customer’s rough specifications are gone through minutely and the solution is defined in more detail before it is accepted. This is done in order to verify that the needs and requirements are covered in an orderly fashion.
MMS 2: At this milestone the developed software is ready to be accepted. Before that during the iterative construction phase the supplier presents a detailed plan for the future iteration rounds, detailed analysis and design is done where needed, prototypes and finished components are presented for the customer, supplier performs testing and further change needs are evaluated and decisions of new iterations are made at the control points (CP), i.e. after each iteration round.
MMS 3: Before the delivery is accepted, it is preceded by the acceptance and conclusion phase during that the installation, acceptance testing, training, implementation and evaluation of the project is done.
According to its name the iterative construction phase resembles, the above reported spiral model for software development. Though using this NTNU model to represent a software contracting process does not specially call for this spiral model as the construction phase could be carried out with any other software development model as well. However, the author of the report has found the spiral model to correspond with his findings and needs best.
2.3.1. Software development contracts
Often the problem with tailored software development is that the object of negotiation has several dimensions that must be taken into account. It directly affects customer’s employees’ work, i.e. it is organizational and it is technical and also complex with connections to other applications as well as other organizations. Sometimes it is hard to know in advance all the future requirements that may even evolve during the development process as the customer starts to understand more about the possibilities of the new application. The distinction of development and services should be made clear in the contracts, i.e. what belongs to the development work and what is the subsequent training, maintenance, services etc. work. Therefore the contract must include terms of when the development process has been ended and when the maintenance and service period starts.
The central issues to be negotiated and agreed upon in a software development contract are the definitions (specifications) of the object, the required rights (copyright and other intellectual property rights), management of the project and future maintenance of and enhancements to the software. A good contract should also include, or at least the parties should understand, negotiation about the price of the applications and the way it is composed of, time schedule for completion, escrow-arrangements, warranties and indemnities, liability and arbitration procedures, cf. e.g. (Bainbridge 2000). It can be seen from the above list in order to negotiate and draft a working contract multifaceted skills and knowledge are required. In addition the negotiations are many times done under time pressure and the negotiated issues are technical and complex in nature and it takes time to bring the parties to the same level of discussion.
The sale contracts are typically used in a tailored software business where the supplier and software developer surrenders all the firm’s rights to the developed application to the customer. This convention has its origins from the view that the customer procures for its own specific software needs subcontracting resources to make the development work. Thus the customer organization just extends its own IT-department (if existing) outside the company limits by consulting assignment. The application is typically so customer specific that neither the supplier nor anyone else gets any benefit from the product. Though this view is changing as the software companies have found that the developed applications however embody possibilities for larger industry usage, perhaps after some modifications to extend the software’s functionality. Also the customer’s have found advantages giving the proprietary software to be further developed and marketed even though the competitors could gain from this. The first benefit is of course financial in two ways as the customer company may get royalties and further development costs will fall. The risk to develop and maintain the software reduces accordingly as the supplier gets more customers it has more incentives and resources to appoint to the specific software. One obvious reason for the use of sale contracts is that many of the subcontracted software companies are small in relation to their customers who thus have totally different negotiation position and power.
2.3.1.1. From the entitlement to the software
There are several generally used methods to protect the rights of developed software. These rights all come under Intellectual Property Rights, i.e. the IPR is an umbrella concept. The importance of this legislation has increased during the last years considerably with a growing and globalized software business. This regulation affects all forms of digitally stored and used medias. The copyright issues play a dominant role in the software business, but also the software patenting has gained ground, starting from the USA and now reaching Europe. In licensing, trade secrets and know-how is shifted from one partner to another thus the relationship must be good and work in the long-term (Nystén-Haarala 1998, 24). Therefore in license contracts a clause not to disclose any critical information that the viable relationship demands is typically included. This can also be stated in the form of a separate contract document called the Non-Disclosure Agreement (NDA) that is drafted for a specific situation or for a longer period that may last years. This short document is commonly used in order to be able to start negotiations in an open mode.
Intellectual Property Rights. Several legal forms can protect the intellectual property rights in the software business. These are copyright, patent, trade secret, trademark[2] and contracts (Nycum 1993). The fact that the regulation is old and it has been passed long ago without the digital era in mind brings problems to enforce it properly in practice. Therefore, using the general legal principle applied throughout in the protection of IPR, Farrell and Warren-Boulton et al. argue that copyright protection should not be given to elements of software that receive a de facto standard status, as this may lead to a monopoly with pricing that would not benefit the markets as monopoly hinders the industry and technology development process (Farrell 1995, Warren-Boulton, Baseman et al. 1995). Other similar elements are the software interface specifications, as this would again prevent other software companies producing similar competing applications. They favour the possibility of reverse engineering, as this would enhance the interoperability between different vendors software (ibid). Opposite standpoints have also been presented as Thurow (1997, 101) suggests that ”free usage of knowledge ends up with societies that create too little new knowledge”. For this reason he argues for a discussion of more production versus faster distribution of new ideas. The decision should be based on economics of the industry to determine the appropriate incentives. The property rights should be enforceable and the resolving procedures of possible disputes should be fast and efficient when carried out (ibid).
Copyright. The first and most commonly used protection method is the copyright law as it automatically gives protection for the next 70 years (from the death of the author) and at the same time it is global. It thus protects the software from unauthorized duplication, use and exploitation (Lim 1996). However, the copyright only protects the manifestation of the software, i.e. source and object code, not the idea, procedure, system or method (ibid). In many cases it may be difficult to judge if the modified software (source code) is same or different, as seen from the perspective of the law. It also protects the program manuals, preparatory design material, databases, as well as almost any form of work made and stored in digital form, if the textual document fulfils the criteria of a literal work in the sense of copyright law. Thus the protection is rather easy to get but it is not very strong and is ambiguous.
The general rule is that the developed software is protected under the copyright law and the rights belong to the producer, i.e. the software company. From this it follows that customers depend on the case and the company policy to obtain varied rights. In the software business field quite obscure opinion about copyright issues concerning software and other material attached to it prevails. Takki (1999) argues for the win-win solution where both parties can protect their own interests. The parties should carefully analyse their true needs concerning the ownership rights needed. If the ownership rights are transferred in the contract then the customer obtains the following types of rights. First, the customer is allowed to copy as many copies as it needs, thus the number of users is not limited. Second, The customer is allowed to further develop the application itself or using third party. This again requires technical capabilities, as the customer does not obtain the source code. Third, the customer is also allowed to transfer the application to a third party, e.g. in case the customer company is acquired or customer’s IT-department is outsourced (ibid). But the customer does not get the source code as it stays in the supplier’s possession and they are not allowed to commercialise the application. If the customer really needs all the rights then the contract must include a statement that clearly indicates this, e.g. the phrase “with all transferable rights” (ibid).
Patent. Patents protect innovative and useful products, processes as well as programs (Lim 1996), see also (Cooter & Ulen 1999, Bainbridge 2000). A patentable product or process must be novel, non-obvious and useful (ibid). The patent gives a stronger form of protection than the copyright. Software patenting started to grow in the 90’s when the United States Patent and Trademark Office[3] (USPTO) initiated granting patents even to software. Software patenting is one of the new important issues that will have a significant effect on the software field. This again demands for clear contracting processes for software companies in order to be conscious what is a proprietary software for the company all the time. With a clear strategy of building own competence and a software base the company builds its own future. The problem with patenting is that the protection it gives is territorial, it is quite expensive and a slow process and the patenting reveals the invention to public. Also the costs of litigation in patent cases are high, especially in the USA. Thus the company applying for a patent must be ready and capable to defend the granted patent. The patent when renewed gives protection up until 20 years. As patent protection is not automatic the companies usually trust special firms that employ patent attorneys to inspect and evaluate the possibilities of patenting the software, i.e. is the software new and innovative enough (involves an inventive step, capable of industrial application) to be eligible for a patent[4].
Trade secret. Trade secrets law protects proprietary information that is used by business and which provides a competitive advantage, i.e. software and software related documents (Lim 1996). Some protection is also derived from the Act of Trade Secrets that enables the parties to conceal confidential information that they have learned from each other during the procurement and software development process. But this is difficult to implement in a watertight manner. Assets that are protected by trade secrets law are e.g. algorithms, techniques, software tools and components (ibid).
As Lim notes software protection can fall under several intellectual property tools (ibid). Some of these can be used simultaneously, but some are exclusionary in their nature, this is evident when the patent and trade secret law is compared. When filing a patent it must be described and disclosed. Thus it is difficult to find the optimal protection, but Nycum gives a procedure to establish the proper protection level for the software:
Choose the asset to protect.
Determine the value of the asset.
Determine the useful life of the asset.
Recognize the vulnerability of the asset.
Determine the time and money available to acquire the form of protection.
Select the form or forms of protection, which best meet the needs (ibid, 414).
In spite of these above intellectual property rights’ tools, Davis et al. (1996) argue for a more effective set of new instruments that pay better attention to the “intangible industrial know-how” as they call it. They reason that the know-how of engineers and designers is not well protected with the present tools. They are “too utilitarian for copyright and insufficiently inventive for patent” (ibid, 30). However, the stream seems to go in an opposite direction according to Davis, as she interprets the new Uniform Computer Information Transactions Act (UCITA) (2000). According to her UCITA interprets software as intellectual property that must be licensed, though the licensee does not own the software and is not able to transfer the license (ibid). The legislation also gives rights to the software producer to include electronic self-help into the software, thus allowing the software company to enter the product e.g. via Internet. The reverse engineering is also outlawed and it allows the supplier extensive warranty disclaimers (ibid). The new act demands more time for negotiations if it is in the interest of the customer and supplier, as the parties are able to agree on the form of the licenses, e.g. to “opt out” the clauses expressed by the UCITA framework (ibid). In licensing, European Community (EC) law and directives[5] have again a different approach, see e.g. (Worthy 1994).
2.3.1.2. Licensing contracts
Software companies use licenses to be sure that the products are used according to the agreement and in a way that benefits them economically. On the other hand the customers want to know the conditions of the software they are going to procure and take into use (Donner 1996). Fig. 11 shows schematically the different phases of licensing operations from the software producer (the licensor) via the dealer, VAR, or OEM distributor[6] to the customer who is the end-user of the software and is granted a license to use the software. With the license agreement the licensor gives the licensee permission to use a copyright, patent, trademark, know-how, or some other exclusive right for a compensation, i.e. royalties. In short, the license is a technology transfer agreement. The licensing is a fast and relative cheap way to go international. Software companies use it extensively and it is the most important contracting form in this business. Fig. 11 depicts a situation which is interesting also from a contractual perspective as the customer actually makes two contracts when procuring licensed software.
The customer makes a sale of goods contract with the dealer and a license agreement with the licensor, i.e. the software producer. The COTS business and to some extent also the MOTS business is easier from the customer’s point of view as the supplier is able to demonstrate the application in advance compared to the tailored approach. The software and applications are the suppliers’ proprietary products and they only deliver the object code[7] to the customer. The license agreement is the most common form of contracting in COTS and MOTS software businesses. Typically the software company that owns the rights of the software gives the customer only permission to use the focal application, i.e. the company grants a license and in this transaction it does not transfer its ownership rights away. The customer again in return pays the license fee. The license may have varying duration, i.e. fixed period, renewable, or there is no indication of the duration. In this case the license covers the software as long as the copyright protection is effective (Bainbridge 2000). The license may give rights to use the application in an agreed environment and extent, i.e. the number of users at a time is agreed. Takki (1999) succinctly describes the applications to be the sum of its technical features and license conditions. If either of these features or conditions do not satisfy the customer then the firm searches a substitute from the markets. Though this is not always possible e.g. in a situation where the supplier has gained a dominant position in the markets with its product or when the supplier owns highly specific and generally vitally important know-how that is not sufficiently available in the markets. In the COTS business it is usual that there are several transactions between the producer, agent and the end-user as depicted in Fig. 11.
The MOTS business is interesting as it includes both the sale and license aspects. The licensing comes from the fact that as described above the MOTS software is built from two separate elements. These are the ready-made part and the customized part, where typically the ratio is from 50 – 90% and respectively 50 – 10%. Thus the ready-made part resembles the COTS business and is licensed to the customer (cf. platform). The other, tailored part – may or may not be sold with all affiliated rights as it depends on the software company’s policy (also customer’s) – is again made under sale contract as in many cases the customized part is to such a degree a customer specific product that there are no reuse possibilities. The software company only derives know-how for further customizing cases. Though in some instances the software components could also be later used in other projects. For the reason of software licensing the existence and scope of intellectual property rights is of fundamental importance (Bainbridge 2000).
A typical COTS license form is the so-called shrink-wrap-license that is prominently used by the distributors when they act as agent for the software producer. The license itself accompanies the application as well as the instructions and other documents included in the package. Also the producer can use this kind of contracting as it is fast and labour saving, as it is not negotiated nor signed. Though the legitimacy of the contract is questionable, if the customer has had the possibility to familiarize themselves with the license text then the customer can be seen to have in a legally binding manner accepted the license, but the binding nature often further requires an opportunity to return the software if not satisfied with the contract text (cf. Donner 1996). However, there are not many proven court cases that would create any precedents. In some states in the USA this kind of license is legal and this has mistakenly indicated that this would be the prevailing convention all over the USA (Hannula & Virmavirta 1994). To let the partners distribute software producer’s applications, the software company must use VAR, OEM, or a distributorship agreement. These are in a sense licenses to license the software package further.
Gifford (1999) argues that a relational contract, which is considered periodically, is optimally less complete than a market contract, which is not directed. Thus the relational contracts are characterized by possibly subsequent periodic attention of supervision, monitoring, consultation and renegotiation. On the other hand the business partners in the case of market contracts do not need to be prepared for further contractual discussions (ibid). These different contractual modes can be exemplified within the sphere of this study as follows. The tailored software business utilizes predominantly relational contracting. The contracts are continuously specified during the software development process accordingly the needs of customer’s and supplier’s growing wisdom of the application under development. The COTS business again relates to the market type of contracts at least in situations where the customer (and supplier) is not interested establishing a long-standing relationship for whatever reason. Interestingly the MOTS business falls between these relational and market modes as it has both elements of these contractual modes. Gifford (ibid) also argues that the license type of contract goes between these two extremes. The primary issue separating the contractual modes is the cost to the supplier of monitoring and controlling the license agreement.
Chávez et al. (1998, 48) suggests that the component license should minimally specify:
“The rights the licensor authorizes the licensee to exercise in the software (license grant),
Payments to the licensor,
Who owns the licensed component and modifications to the licensed component,
The risks and liability each party assumes under the license,
Support, maintenance, and warranties for the licensed component, and
The confidentiality of the licensed component”.
They further discuss the differences between the commercial exploitation possibilities and ways of the COTS and component software and their effect on licensing issues. According to them, both cases require different approaches to formulate the licensing agreements (ibid).
2.3.1.3. Managerial issues
A typical managerial arrangement is depicted in Fig. 12. As a general rule software development is done in a project organization. When the developed application is large enough two separate groups to administer smooth project flow is agreed in the contract (Tähtinen 1999). The first is usually called the steering committee that is put together from the customer and supplier’s management representatives. They have ultimate decision rights concerning questions that need to be answered immediately or that the project group is not able to decide. The steering committee is responsible for the finances of the project and it is responsible for changes that have contractual implications. Usually the project managers from both companies are represented in the committee, this is so that they are able to bring the information from the project group to the committee members and vice versa.
The project group is again put together from both companies’ IT- and software experts and sometimes also future users are represented here. The project group is the resource that actually fulfils the contractual obligations. The management of the software project varies greatly and is dependent on the customer’s and software company’s operating policies, quality systems and other operational procedures as well. The parties must decide on how decisions are made and what the approvement procedure used during the cooperation is.
2.3.2. Software contract templates
The same laws that are applicable in general commercial and contractual law can feasibly be used in the software business. However, the company law itself can be perceived as one form of contract templates that both parties may capitalize in order to save transactional costs. Though software has its peculiarities, e.g. it is not tangible, it often includes services and the procurer finds out about the product only after the contracts have been signed in the case of tailored software. Thus the software business has its own characteristics that need for special laws that address these questions (Augustson & Begstedt-Sten 1999). This is one of the reasons why the line of business has developed its own contract templates to facilitate the contracting procedure between the customer and supplier.
Standard contracts in software business are used, as the business itself is complex and emphasized by fast development of different cooperation forms as well as different business models. Standard contracts easies both customer’s and supplier’s confidence on the quality of the contracts and enables a better comparison between different suppliers’ offers. Also the known and open contracts can be better distributed in the organizations. However, in some cases the standard contracts can be difficult to use as they may have clauses that are not justifiable in some specific cases. The parties should also understand when not to use the standard contracts as they must still be regarded as directive and the users must understand the issues included in the templates and the peculiarities of their focal software field (Christner 1995). Standard contracts can be drafted by one of the partners or the partners together. In some cases the templates can be made by the industrial organizations’ IT2000 templates (Keskuskauppakamari 2001). If the templates are drafted by one of the partners then this organization may strive for a better legal status compared to the adverse party, which can cause problems for their binding force from the legal point of view.
The IT2000 templates are aimed for business-to-business contractual relations between supplier and customer in domestic delivery, even though an English version of the contract templates also exists. The Finnish Central Chamber of Commerce, The Finnish IT Services Association, The Finnish Information Processing Association and The Finnish Logistics Society have drafted them jointly. They have been looked over by the supplier’s and customer’s representatives. The contract package also includes instructions for the use of the templates, e.g. mentioning that in a company specific mode of action and in demanding and complex deliveries it is better to agree case-by-case additional and special conditions. Among other things, phasing the total delivery project (definition, execution, piloting and delivery) depends on and varies between agreed projects. The package contains the following elements and contract drafts:
General Terms and Conditions,
Special Terms and Conditions for the Delivery of Customized Software,
Special Terms and Conditions for Deliveries of Standard Software,
Special Terms and Conditions for Deliveries of Equipment,
Special Terms and Conditions for Consulting and other Professional Services,
Special Terms and Conditions for Equipment Maintenance,
Special Terms and Conditions for Software Maintenance and
Terms and Conditions for Small-Scale Deliveries.
The special condition templates are meant to be used together with the General Contract Conditions template. Tailored software (tailored and MOTS) and packaged software (COTS and MOTS) have separate templates as they include notable differences e.g. right to use, right to make changes, acceptance practices and warranties. The starting-point is that the copyright of the software and of the results of the services resides with the supplier and the customer gets the defined right to use in the contract. The basic idea is that delivery phase has its own contract and service, the maintenance and support phase has their own contracts. Still these should be made simultaneously.
The contract templates offered by Tieke – Finnish Information Society Development Centre[8] – are targeted to those software companies that are going to enter the export markets, thus they are drafted in English. They cover and give advice on international software contract negotiations and contract law issues with commentaries. The database contains some twenty different basic contract templates. During the 90’s Swedish software organisations produced a collection of contract templates to be used in the software business. They include Contract 90 (Avtal 90), which concentrates on tailored software development and delivery, Maintenance 90, Development 92 (SITO), Services 92, Telecommunication services 93, Leasing 93, ABDAKA 96 for IT-consulting. However, the supplier’s side drafted all these templates whereas the outsourcing template for Providing IT-Machine Services has had a broader participation from the industry (Christner 1995, Augustson & Begstedt-Sten 1999).
The opinion for standard contracts varies prominently e.g. Lacity and Hirschheim (1993) advise the outsourcing customer to discard the vendor’s standard contracts. They emphasize the one-sided view of these contracts. According to their experience, the contracts do not include performance standards nor penalty clauses for non-performance situations. This view can only be supported if the templates are drafted by either side alone and only with their own advantage in mind. However, if they are formulated by the line of business organizations, they at least should be more balanced. Their perspective is also a typical example found in U.S. literature covering software contracting from the customer’s side. They see the software or service provider as a suspicious entity, more about this attitude see e.g. (Peterson & Carco 1998). Marciniak and Reifer (1990) introduce some key elements included in U.S. software contracts. U.S. contracts include labour (right to belong to labour union and how disputes are mediated) and socio-economic (race, colour, religion, etc.) clauses.
2.3.3. Customer perspective – software acquisition standards
Of all of the objects of software engineering, process is the one which receives the most attention today. It is commonly believed that the implementation of a sound software development process is strongly correlated with the production of high-quality software products. Of course, this attitude is not unique to software development – the ISO 9000 standards apply the same premise to the manufacturing of systems (Moore 1998, 187).
A few software acquisition and procurement standards exist that provide rather formalized and deterministic guidelines for companies that consider purchasing some software product. Buying organizations have also used maturity models to support their software procurement processes (Rugg 1993), for example the Software Acquisition Model, SA-CMM[9]. A software supplier company can also use these as guidelines, when preparing to give an answer to the RFP. In the following is analysed briefly the ISO and IEEE standards that concern software acquisition.
The software acquisition process is a part of the so-called Primary life cycle processes that serve the parties during the life cycle of the software in the ISO/IEC 12207 standard (1995). In the ISO/IEC defined initiation activities the customer should prepare, document and execute an acquisition plan where the software acceptance strategy, conditions, and alias criteria, are defined. The contract preparation and update activities include tasks meant to establish a procedure for supplier selection, including proposal evaluation criteria and requirements compliance weighting. The standard describes the requirements for the actual software supply process, focusing on how to carry it out effectively.
The ISO/IEC 14598-4 standard (1999) is intended for organizations that are planning to acquire an existing or pre-developed software product. It contains requirements, recommendations and guidelines for the systematic measurement, assessment and evaluation of software quality during the acquisition of COTS, tailored, and MOTS products as well as of the modifications to existing software products. The standard may also be used for software product selection purposes, deciding on the choice or acceptance criteria of the product. The processes described in the standard aim, however, more towards ensuring the quality of the software to be acquired than on evaluating the supplier’s capabilities and processes.
The IEEE Computer Society has published two standards related to software acquisition. IEEE Std 1062/1998 (1998) gives recommendations on software acquisition. Among other things, it describes practices for evaluating and qualifying the supplier’s capabilities of meeting the customer’s requirements. This standard uses recommended practices to classify software products by the degree to which the acquirer may specify the features of the software: COTS, MOTS and fully developed items (tailored). In the IEEE standards one of the key milestones of the software acquisition process is contracting that includes three steps: (i) identifying potential suppliers, (ii) preparing contract requirements and (iii) evaluating proposals and selecting the supplier. Identifying a potential supplier includes the following activities (ibid):
Gather information on available software products,
Evaluate software during a demonstration,
Survey users of the supplier’s software,
Review performance data from previous contracts and
Survey several suppliers’ offerings.
The process for evaluating proposals and selecting the supplier is designed to ensure that only skilled and responsible suppliers are being selected. This includes at least the following activities: evaluate supplier proposals, visit supplier facilities, select a qualified supplier and negotiate the contract. The recommended supplier evaluation checklist addresses the following aspects: financial soundness, experience and capabilities, development and control processes, technical assistance, quality practices, maintenance service, product usage, product warranty, costs and contracts.
The IEEE standards provide far more exact supplier screening processes than the ISO standards. In particular, the former include rather precise checklists for evaluation purposes, whereas the latter are more open. The standards include some guidance for software suppliers, but mostly for fulfilling the customers’ quality requirements.