Syndicated Community Bank: Core Banking Systems Replacement Project "This project is more about quality control than quality assurance," said the CTO. The reason behind the CTO's comments was the implementation of the COTS system by the vendor for the CBS project at SCB. Quality control was mostly accomplished by the IT department of SCB by testing the software after it was installed by VendorB. The IT department of SCB continuously tested the implemented software by inputting dummy transactions to ensure quality. Once the IT department confirmed that all the tests were completed, the business units also tested the software. There were several mock conversions that were planned on a timed schedule as well to test the software completely. The timed schedule worked with a clock set for the process to be followed through the intended mock transactions. The software also had very minimal customizations that were accomplished by VendorB. Even though the software was from a third-party software developer, quality reviews were also planned to document the testing of the software. SCB completed a number of quality reviews and tested the software over and over many times. Quality reviews that were conducted included:

• Expert reviews;
• Peer reviews;
• Team reviews;
• Formal reviews;
• Management reviews; and
• Process review.

The basic idea of using COTS was to reduce the time to market by shifting the developer resources from the development of the software to integration and testing. In the case of SCB, there was another advantage as the COTS software developer was implementing the software. There are some disadvantages, such as integration difficulties, performance constraints, and incompatibility among products from different vendors. In deciding between in-house development and COTS component acquisition, software engineers must consider the anticipated effect on system quality such as:45

• The measure of the COTS that satisfies a user's requirements and expectations;
• The measure of value of the COTS to stakeholders;
• The measure of quality of COTS with respect to its performance and reliability; and
• The measure of the software development process.
• The four main reasons for using COTS are:
• Software is readily configurable to meet specific intended functions;
• Large user community;
• New technologies that are hard to develop;
• Rapid delivery to end-users; and
• Cost.

The requirements, specifications, and processes of the new core software were defined as if the application were to be developed by SCB and were scrutinized during the audit process. There is a factor in COTS implementation that is often ignored: the volatility of COTS, the frequency with which a COTS vendor releases new versions of its software. This factor has been identified as one of two primary determinants in the cost of using COTS software, the other being the actual size of the interface or "glue" code needed to integrate a given COTS product. Stutzke suggested a model quantifying the added cost associated with using a COTS product that has a significant volatility as:

• CV=component volatility (number of new releases of the COTS component over life of the project)
• AC=architectural coupling (number of other components which interface with the given COTS component)
• IS=apparent interface size in terms of the number of entry points, procedures, functions or other methods used to access the COTS component, weighted by the number of arguments passed
• CS=cost of screening the COTS component and all the other components with which it interfaces to determine the impact of a new release
• CC=cost of making changes to impacted components

What different metrics should be used for the projects using COTS? Why should the metrics for the projects using COTS be different than traditional software development projects? Why did the CTO say that "the project is more about quality control than quality assurance"? Of the quality reviews proposed, which one is the best? Why?