Customer Configuration Updating (CCU) is a software development method for structuring the process of providing customers with new versions of products and updates production. This method is developed by researchers of the Utrecht University.
The delivery phase of the CCU method concerns the process which starts at the moment a product is finished until the actual shipping of the product to the customer.
Introduction to the delivery process
As described in the general entry of CCU, the delivery phase is the second phase of the CCU method. In figure one the CCU method is depicted. The phases of CCU that are not covered in this article are concealed by a transparent grey rectangle.
As can be seen in figure one, the delivery phase is in between the release phase and the deployment phase. A software vendor develops and releases a software product and afterwards it has to be transported to the customer. This phase is the delivery process. This process is highly complex because the vendor often has to deal with a product which has multiple versions, variable features, dependency on external products, and different kinds of distribution options. The CCU method helps the software vendor in structuring this process.
In figure 2, the process-data diagram of the delivery phase within CCU is depicted. This way of modeling was invented by Saeki (2003). On the left side you can see the meta-process model and on the right side the meta-data model. The two models are linked to each other by the relationships visualized as dotted lines. The meta-data model (right side) shows the concepts involved in the process and how the concepts are related to each other. For instance it is visible that a package consists of multiple parts, being the: software package, system description, manual, and license and management information. The numbers between the relations indicate in what quantity the concepts are related. For example, the “1..1” between package and software package means that a package has to contain at least 1 software package and at the most 1 software package. So in this case a package just has to contain 1 software package. On the left side of the picture the process-data model is depicted. This consists of all the activities within the delivery process. This article is based on this process-data model. The meta-process model (left side of the process-data diagram) is divided into several parts which are presented along with the corresponding paragraphs throughout the article to make it easier to understand.
The tables that describe the concepts of the meta-data model and the activities of the process-data model are presented beneath figure 2.
Table of concepts The table of concepts contains all concepts used in the meta-data model with their explanations along with the source from which the explanations are derived.
Table 1: Table of concepts {| class="wikitable" width="90%" |- style="background:silver;" |Concept |Definition (Source) |- |REPOSITORY |Also called a vault. A repository contains only one complete version of a configuration item (CI). Differences between versions are usually stored using a delta algorithm.
Collection of records describing resourcesCarzaniga, A. & Fugetta, A. & Hall, R. & van der Hoek, A. & Heimbigner, D. & Wolf, A. (1998) A characterization framework for software deployment technologies. |- |package |A collection of different related items combined for transferring purposes to the customer. |- |SOFTWARE PACKAGE |A collection of different related software components combined for transferring purposes to the customer. |- |SOFTWARE COMPONENTS |The different components of which software consists related through dependencies. |- |VERSION |A version is a state of an object or concept that varies from its previous state or condition. |- |SYSTEM DESCRIPTION |Description of the system including its requirements and the dependencies on other external components. |- |manual |A technical communication document intended to give assistance to people using a particular system. |- |LICENSE |Type of proprietary or gratuitous license as well as a memorandum of contract between a producer and a user of computer software that specifies the perimeters of the permission granted by the owner to the user. |- |MANAGEMENT INFORMATION |All the information that is relevant for the management of the system at the customer site. |- |CUSTOMER RELATIONSHIP MANAGEMENT SYSTEM |A system which maintains all information about the customers.S. Jansen & G. Ballintijn and Sjaak Brinkkemper (2005). Definition and validation of the key process areas of release, delivery and deployment for product software vendors: turning the gly duckling into a swan. In Technical Report CWI, 2005. Report. Retrieved February 8, 2006 from Computer science University Utrecht database. |- |CUSTOMER |A company or person that bought some product or made use of one of your companies services before. |- |LICENSE TYPE |In this case it can either be a long term license, an expired license or a temporary license. |- |CUSTOMER DATA |All known information about the customers in the customer relationship management system. |- |CONFIGURATION MANAGEMENT SYSTEM |A system maintaining information about the software configurations at the customer sites.(Prince2 CCTA, 2002) |- |PRODUCT |An element of software or a document placed under version control.(Crnkovic et al., 2003) |- |UPDATES |An update also called a patch is a small piece of software designed to update or fix problems with a computer program |- |CONFIGURATION |A configuration is an arrangement of functional units according to their nature, number, and chief characteristics. |- |MODIFICATION |Modification is the act of applying change to an original. |- |FEEDBACK |Feedback allows a vendor to gather large amounts of data about its customers and its product as it acts in the field |- |BUG REPORT |A report of the problems users encountered using the product. This can mean a problem with a certain function or dead links within the system. This information is collected manually. |- |PRODUCT USAGE DATA |This data contains information about the actual product usage. This reflects on options that are most used within the program. |- |ERROR REPORT |When the software product gets an error it will automatically send an error report to the vendor. |- |USAGE QUESTIONS |Questions users have about handling the product etc.
Activity table The activity table contains the explanations of the activities along with the source from which the explanations are derived. Because the method is quite innovative a lot of the activity's are designed especially for this model and therefore the explanations do not have a source.
Table 2: Activity Table
{| class="wikitable" width="90%" |- style="background:silver;" |Activity |Sub-Activity |Description (Source) |- |colspan=2 |package |Packaging the system so that it can be transferred to the customers’ site. |- |rowspan=6| |package software |Combining different software components into one package that can be delivered to the customer. |- |package system description |Add a system description to the package. |- |package manual |Add a manual to the package. |- |package license |Add a license to the package. |- |package management information |Add a management information document to the package. |- |Check package |Make sure that the package is complete and ready for deployment at the customer site. |- |colspan=2 |Advertise update |When a vendor wishes to provide updates to its customers, the customers first need to be informed through the available communication channels. |- |colspan=2 |Prepare distribution |Prepare measures be able to get the software to the customer. |- |rowspan=2| |Set package in repository |A finished software component will be made available in some release repository.S. Jansen & G. Ballintijn and Sjaak Brinkkemper (2003). A process model and typology for software product updaters. Conference on Software Maintenance and Reuse. IEEE. |- |Create transfer channels |The vendor needs to create channels through which the software can be transferred to the customer. |- |colspan=2 |Distribute |Getting the software to the different customers.(Crnkovic, Asklund & Persson-Dahlqvist, 2003) |- |rowspan=5| |customer request |A customer makes the vendor aware of his interest for a certain product or update. |- |Determine configuration needs |It is determined which software components are needed for a successful configuration update. |- |Determine configuration constraints |It is determined to which constraints the infrastructure of the customer has to suffice in order to run the new product or update. |- |Check customers license |It is checked if the customer is in possession of the right license for the new configuration update. |- |Deliver update |Getting the software components at the customer site. |- |colspan=2 |Inform customer |Providing the customer with information about in this case the status of its request. |- |colspan=2 |Update CRM |Add information to the CRM system so that it contains the most current information available. |- |colspan=2 |Receive delivery and deployment report |Getting a report (automatically or manually) about the success of the delivery and deployment from the customer. |- |colspan=2 |Update license type |Add information about the license obtained by the customer so that the system contains the most current information available. |- |colspan=2 |Update configuration management |Add recent information in the configuration management system, so that the customer most recent configuration is stored.
|Update product properties |Renew the information about the products in use by the customer so that the system contains the most current information available.
Package software
In order to deliver the developed product to the customer, the vendor needs to package the different components of its product into a package. By doing this, the customer will receive all the information and software components at once fulfilling all its needs. After combining all elements into one package the software vendor will carefully have to check if the package is complete. The package will have to provide the customer with all the tools and information to use the product. When this is not the case the software vendor will get a lot of questions from its customers which will consume a lot of time. It is therefore very important that the package is checked carefully before it is shipped. The package can be a physical combination of different elements packed into for example a box, but it can also be a digital combination of files which contain all the elements. Within the CCU process it is stated that a package will consist of five elements, being: software package, system description, manual, and license and management information. In the following paragraphs is explained how these elements fit into the CCU delivery phase.
Software package One of the elements of the package will be the software package. The software package is a package in itself, because it consists of the different software components that together form the product. In contrast with the overall package, the software package is always a technical package in which all the files needed are combined in order to run the software product.Examples of tools which can perform this packaging are: Loki-Update , RPM-update , SWUP and Portage . Another concept of the software package is the version. This keeps track of the modifications made to the software product. By relating it to the software package the vendor and the customer are able to keep track of the functionality and properties of the product the customer is using.
System description