Qualitative Assessments of the Software Architectures of Configuration Management Systems

: The Configuration Management (CM) is a very important area of concentration in software development and maintenance processes. Quality parameters for Configuration Management Tools’ architectural designs require rigorous identification and measurement. Two methods for quantitative assessment of quality parameters of the software architectures are proposed. These methods are based upon modularization properties, like, cohesion type, coupling type, module complexity, module size and others. Looking at the problems with the studied tools, like, low flexibility, interoperability, etc., and recent requirements for the CM tools, a new architectural model has been proposed [1] . All the three models are assessed on quality parameters applying both the methods with an objective to validate the superiority of the proposed model.


INTRODUCTION
Software Configuration Management (SCM) is the supportive activities, which go along the whole software development and maintenance cycles. SCM takes care of making the changes in a managed way. Some of the fundamental activities of software configuration management are configuration identification, version control, change control, status accounting and reporting, and configuration audits. Firstly, configuration identification and version control deals with storing software process artifacts with proper version numbers in a data bank called repository. Secondly, change control deals with making changes in the established artifacts in a systematic way. Thirdly, status accounting and reporting works regard storing information, like, when the change was made, who made the change, etc. Lastly, CM audits verify and validate that the changes have been made as desired.
Software architecture is an area, which referrers to the architecture's components and their interconnectivity The software architectural design is the first artifact of the design phase.
Although the Quality attributes of software are specified by different sources, like, McCall and FURPS [2] . They address combination of product revision, transition, and operational aspects of the software. Out of the available quality attributes, it requires filtering to decide the quality attributes (parameters), which are relevant to the architectural design of the SCM tools. Under the present research, the quality parameters relevant to software architectural designs of SCM tools are identified, they are flexibility, interoperability, availability (ease of repair), testability, traceability, portability, and simplicity.
Most of the existing CM systems have three layered architecture [3] . The layers from top to bottom are policy support, basic CM services, and repository. This is referred as the architectural design of the 2 nd generation tools. This suffers from lack of flexibility and interoperability due to large module sizes, as modules here, implement numerous functionalities and mixed features [4] . A better architecture from Software Engineering Institute, CMU, USA is the 'CM Services Model,' it offers number of atomic CM services (reducing the module sizes), out of which users can choose the relevant ones. It is a client/server system. It has a problem of over modularization (very small module sizes), which leads to large integration testing efforts. Also, it does not have any specific provision to interoperate with other CM tools to take advantage of their stronger features.

METHODS FOR QUALITATIVE ASSESSMENTS OF ARCHITECTURES (SCM TOOLS)
Here, method # 1 and method # 2 are proposed, for evaluating the quality attributes of architecture.
Method No. 1: Here, we try to define some quality metrics. A metrics should be measurable and be able to quantitatively reveal the differentiation in the values of attributes of the entities for which metrics are defined. Note: Pre-requisites for these methods are that the requirements should be well defined and software architectures of the various tools must be understood well by the person applying these methods. Transaction process: This category used simple and small programs of transaction processing or batch processing, which does not involve much of decision making, but they are composed of simple data representation and access. Programs here do not have much decision making criterion. M1: Assessment of cohesion and example: Let us consider an example of low cohesion, a module that performs error processing for an engineering analysis package. The module is invoked when some input validity check is violated. Then, it performs following functions: Generate supplementary data form original, Generate error reports for user, perform calculations as requested by user, update data in database and displays main menu for further processing request. All these preceding tasks are loosely connected, because they are different in nature. Here, we can say that each is a different and functionality independent and will perform best in individual mode. In-case we combine these into one module, then chances of error propagation are high, if one of them is modified. This makes the collective cohesion to be of low magnitude. For such cases cohesion type could be assumed to be procedural or a bit less than that. 2. We derive two formulas, here, multiplication is used instead of average, since in most of the cases individual cost drives are multiplied to achieve the final values: Modularity (MOD) = M1*M2*M3; MOD is a metrics trying to represent how well consolidated and functionally independent the modules is. Best MOD situation is: high cohesion, low coupling and low fan out of modules. Complexity (CMPX)= MF1*MF2. 3. Here, an attempt is made to understand following quality parameters of CM tools [2] : Simplicity (SMP) it depends on the complexity of the module, which could be calculated by formula for CMPX = MF1*MF2, so we will use the same rating of CMPX to rate simplicity in a reciprocated way (10-CMPX). Traceability for correctness and communicativeness, it will depend on the modularity, MOD = M1*M2*M3, so we will use the same rating of MOD to rate traceability. 4. The other quality parameters, which are considered for the purpose of the assessing the quality of any CM tools are also based on "modularity" quality metrics as mentioned in the relationship of McCall's software quality factors and quality metrics [2] . They are reliability, maintainability, flexibility, testability, portability, reusability, and interoperability. They are all dependent on modularity quality metrics. We will primarily use MOD as their full or partial rating basis. At the moment we will be including flexibility, testability, portability and interoperability only for assessing the CM tools, as others are not the implicit or explicit requirements of CM tools. 5. As per the relationship between McCall's software quality factors and quality metrics [2] , we find that flexibility and testability are dependent on the complexity also, this is in addition to their primary dependency on modularity, so for their ratings CMPX and MOD both are incorporated. Now we introduce another metrics COM, which will indicate logical simplicity and strength of modularization of a module: Rating (COM) = sqrt ((10-CMPX)*MOD), if module coupling and/or fan-out information is not available at architectural design level, then we will use M1 instead of MOD. So, Rating (COM) = sqrt (M1*(10-CMPX)) 6. For interoperability we will use MOD and data commonality and communication commonality, but since at architectural design can not do much to incorporate the later two parameters, we shall be confined to MOD only; if module coupling/fan-out information is not available at architectural design level we will use M1 instead of the whole formula. On the same lines portability is to be assessed, since other parameters apart from modularity are not incorporable at architectural design stage. 7. For coupling or any other parameter if multiple answers are received we take the average of the ratings. 8. We can take another parameter in consideration termed as "availability" is the probability that system will be available in operational state. Here, we mean to take availability directly in terms of ease of repairing or in general maintainability. It is proportional to reliability so, again as per the relationship between McCall's quality factors and metrics [2] the metrics for maintainability are taken for the same purpose for availability/ease of repairing, again as it is seen that maintainability depends on modularity and complexity (simplicity). Good cohesion helps to reduce mean time to repair (MTTR) by helping fault diagnosis. This makes the system available for operations. So, availability will be treated the same way flexibility is, Rating = sqrt(MOD*(10-CMPX) or Rating = sqrt(M1*(10-CMPX)); if required information to calculate MOD is not available at architecture design stage. 9 In case there are more than one special components for a single quality parameter, COM or MOD for both the components will be increased by 1. Along with this if one special purpose component supports more than one quality parameter then its rating should be increase for both the parameters in terms of MOD and/or COM as the case may be.

Option 2
1. If there is a component which is dedicated for any one quality parameter. It will receive weight-age of 80%, rest of the COMs or MODs related to rest of the components will collectively get a weight-age of 20% (Parato principle: 80% of output are caused by 20% of components, and rest 80% of components cause 20% of the output ). 2. If there are two components C3 and C5, contributing towards one quality parameter, the weight-age of 80% shall be divided between the two preferably equal. Unless there is a strong reason given. 3. If one component supports more than one quality parameter then in both the cases and will get a weight-age of 80% in both the cases.
Option 3: Now, we can specify any special adjustment to be done on the rating for a particular component DEDICATED FOR SOME specific quality parameter, after it has been populated as per the formulas given. This special adjustment could be increasing the existing rating by 25% or any other amount, due to the presence of a special component for a particular quality parameter. Also, you need to give this component weight-age of 80% and spread rest 20% to rest of the components just the way option 2 has been processed.

RESULTS
On applying these methods on three different architectures of configuration management tools following results were obtained ( Table 2). Brief descriptions of the architectures are given here: Architecture 1: 2 nd generation CM tools' architecture: It is a layered architecture, the bottom layer is repository, the middle layer offers all configuration management services and top layer offers management of configuration management documents, like, plan, policy and procedure. Each layer here is treated as a separate component.

Architecture 2: CM services model:
It is a clientserver model. All basic CM services, like, configuration identification, change control, CM audits, and status accounting and reporting are implemented in around 50-55 small functions (sub-modules), available on server. Different users (role players) copy the required services from the server in their workspace available (private work area having the relevant files) on the client machine.

Architecture 3: Proposed architecture:
Although the proposed architecture consists of 15 components, but only 11 have been taken into consideration. This is due to the fact that others are optional services [5] . The components are listed below:

C1: Users/subcontractor (general) interaction and relationship management
Discussion: This module will be of substantial size and will have facility to interact with the users, like, project manager, configuration manager, software engineer and the customers. We can see that this module will be doing some predictive analysis regarding, who can request what, it will keep a good communication and co-ordination, so the following ratings could be given. Type of cohesion = functional, since this module is independent of other modules Types of coupling= no direct coupling and data coupling MF1 = 7, since the application type is business analysis( prediction and co-ordination.) MF2 = .8 since module size is above average. So, Fan-out (Appx.)= 2, so M3=1 Modularity will be equal to MOD=M1*M2*M3 = 10*(1 +.85)/2= 9.25 and, Complexity CMPX = 7*.7=4.9 = 5(appx.), C2: Change request and component traceability, change dependency analysis, distributed development feature (change set) [6,7] . C3: Artifact Access brokering/Access permission/Repository access control: C4: Dynamic Process Specification: CM process Specification [8][9][10] C5: Process Monitoring: Status reporting and accounting C6: Process Control: CM reviews and audits C7: Component based development support module [11,12] C8: Deployment function Module [13,14] C9: Rapid Application Development process Support Module [15,16] C10: Interface based on event driven implicit invocation to make CM system interoperable, this would consist of a rule component to select appropriate CM tool for its required feature. C11: Configurable Data router to route the data to appropriate tool.

Advantages
* Methods are based on most fundamental modular properties of cohesion, coupling and fan-out. The set of metrics used for complexity calculation is size and the type of application, which have very little component of subjectivity in them. So, there is no need for taking multiple samples of ratings from different people, this saves time and effort, so methods are very efficient. Also, the use of fundamental properties to form the basis of the methods, makes the methods direct and applied. * The other metrics, which are derived, like, COM, MOD, SMP, and CMPX are based on simple mathematical operations. They do not involve major statistical tools. Only sum and averages are applied to them to take out the values of quality parameters (flexibility, interoperability, and others). * In second method three options are pursued to handle special purpose components, the last two options are based on widely used 80, 20 rule given by Pareto, and at the end to make comparisons the average of all the three options used, which makes the method very reasonable and statistically sound. * While working out these methods the total time required to apply both the methods, and come out with quality parameter ratings for all the three architectures was about 2 hours. This was with an assumption that the complete idea of architectural designs was available in advance to the person applying the methods, which in any case is the prerequisite..

Drawbacks:
These methods can be used only by people, who are knowledgeable in areas, like, software architecture, modularization and its properties, types of cohesions and coupling, and definitely the domains of software configuration management or domain of the architecture application (in general). This all is required as we need to do a rating by recognizing the cohesion and coupling types present in any component (module) of the architecture. That's why it is difficult to get ratings form multiple people and observe the deviations or do statistics on them.

DISCUSSIONS AND CONCLUSIONS
Here we compare the results of the two methods, the results comprise of quantitative rating of various quality parameters present in three different architectures of CM tools: "2 nd generation," CM Services Model" and the "Proposed Architecture Model". As per Table 2 the value of interoperability is significantly high in case of proposed model, this due to the presence of special components, C10 (Interface to other tools) and C11 (configuration data router). Same results could be seen for flexibility of proposed model, due to average module sizes and special component, C11 (configuration data router). In other parameters, like, traceability, testability, portability, the proposed model has also done the best. As we see "CM services Model," is best in case of simplicity, because it is offering discrete atomic service for each of the requirements (mostly representing configuration management activities). The proposed model having average number of modules and average module size, thus it is free from the problems of undermodularization and over-modularization. Whereas, the CM services model suffers from over modularization, due to atomic module sizes and 2 nd generation model suffers from under modularization, due to large module sizes. Big module sizes, inherently reduces the testability due to the presence of multiple features, which require large and complex test cases, which are difficult to compose and apply. In case of small module sizes, as present in "CM Services Model", the integration testing overheads (stubs and driver preparation) takes the efforts to the higher side. Although, no special attempt has been made in terms of introduction of special components in case of 'availability' in proposed model, but due to better cohesion and limited complexity the ratings are far better in case of the proposed model. This validates the fact that the proposed model is superior than the other models in majority of quality parameter of its architectural design.