Sign In to Follow Application
View All Documents & Correspondence

Method For Predicting Maintainability Of A Software Application

Abstract: A method for evaluating the maintenance effort of the software application is disclosed. The method includes identifying the list of process quality metric parameters (PQM parameters) that impact the maintainability of the software application, computing the values for the identified list of PQM parameters. The method further comprises determining the maintainability index (MI) of the software application and further evaluating the maintainability of the software application. The Maintainability Index for 95% of the software applications is in the range of 1 to 10. The software application can be either a JAVA class or a COBOL program. The threshold MI Value for JAVA Class and COBOL program is 3 and 5 respectively. The JAVA class requires less maintainability if the threshold MI value falls 3 or above on a scale of 1 to 10. The COBOL program requires less maintainability if the threshold MI value falls 5 or less on a scale of 10 to 1. Further, the MI of the software application is not comparable by their indices.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
08 April 2008
Publication Number
42/2009
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
Parent Application

Applicants

INFOSYS TECHNOLOGIES LIMITED
PLOT NO 44 & 97A ELECTRONICS CITY HOSUR ROAD BANGALORE 560 100

Inventors

1. RAO, PRITI
8 & 9 CASCADE WAKAD ROAD, WAKAD, PUNE 411057
2. KULKARNI, NITIN
FLAT NO 21, BUILDING 3B-1 NEW AJANTA AVENUE OFF PAUD ROAD, KOTHRUD, PUNE 411038
3. AMRE, HARESH
B2/401, MONT VERT FINESSE PASHAN-BANER LINK ROAD PASHAN, PUNE 411021
4. DANDEGAONKAR, HEMANT
C-15/17, WEST END VILLAGE S.NO.101, BHUSARI COLONY KOTHRUD, PUNE 411 038
5. PATWARDHAN, VAGEESH
4A/4B MANTRI RESIDENCY II BHAU PATIL ROAD BOPODI, PUNE 411020
6. KUMAR, JITENDRA
A14/404, PLANET MILLENNIUM PIMPLE SAUDAGAR PUNE 411027
7. JOSHI, SAMEER GOVIND
A-20, ANUBANDH APARTMENTS SINHAGAD ROAD, NEAR RAMKRISHNA MATH PUNE 411030
8. POL, MILIND
ROW HOUSE #9 PLANET MILLENNIUM AUNDH-ANNEX, PUNE 411027
9. GUPTA, DHEERAJ
9, GIRRAJ NAGAR INSIDE FORT, BHARATPUR-321001
10. BANERJEE, AMITAVA
20, KAILASH BANERJEE LANE P.O. BALLY, DIST:HOWRAH WEST BENGAL 711201
11. REKHI, SUJIT
B-302, SOHAM ETERNITY ASHIYANA PARK PHASE II OPP ANANDBAN CLUB AUNDH, PUNE 411007
12. KAKKAR, PANKAJ
C/O MR K.C. ANAND 21 EC ROAD, DEHRADUN-248001

Specification

BACKGROUND OF THE INVENTION
The invention relates generally to maintainability of software applications, specifically a method to predict the maintainability of a software application coded in Java or COBOL.
Worldwide studies reveals that approximately 35% of the total IT budget of organizations is spent on maintenance of IT systems. This makes it extremely important to invest in bringing down the maintenance part of the total cost of ownership. The total cost of ownership of software is inversely proportional to the quality of the software.
Software Quality metrics can be classified into three categories namely product metrics, process metrics, and project metrics. Product metrics describe the characteristics of the product such as size, complexity, and design features. Process metrics are used to measure the ability and maturity of a process to develop software solutions. Examples are effectiveness of defect removal during development, and response time to fix defects. Project metrics describe the project attributes and execution parameters. Examples are the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity.
Compliance to process quality performance measures is not sufficient alone to ensure maintainable, reusable and extensible code. Engineering (product) quality is equally important to ensure Maintainability, reusability, extensibility, testability and reliability. Traditionally software organizations have had a tendency to focus on process quality more than product quality.
Maintainability is the ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment. Applications grow so complex over years that a small change in the environment results in excessive effort being spent to adapt the application. Maintainability is the inverse of code complexity. Higher code complexity results in lower maintainability.

PQM (Product Quality Metrics) is an initiative to measure and improve code quality. It provides a quantitative measure of code quality which would otherwise be a subjective, manual evaluation. The metrics allows identifying classes / packages that will need higher testing and maintenance effort.
Conventionally, Oman et.al had developed an equation that calculates Maintainability Index (MI) of a software application using a combination of widely-used and commonly-available measures. Oman used the computed MI to assess the software application's maintainability. The basic MI of a set of programs is a polynomial of the following form (all are based on average-per-code-module measurement):
MI - 171 ^ 5.2 * In(aveV) - 0.23 * aveV(g') - 16.2 * In (aveLOC) + 50 * sin (sqrt(2.4 * perCM)) where the coefficients are defined as follows:
aveV ~ average Halstead Volume V per module (see Halstead Complexity Measures)
aveV(g') =" average extended cyclomatic complexity per module (see Cyclomatic Complexity)
aveLOC = the average count of lines of code (LOC) per module; and, optionally
perCM = average percent of lines of comments per module
Oman developed the MI equation forms and their rationale and his study indicated that the above metrics are good and sufficient predictors of maintainability. However, the existing MI equation developed by Oman is limited in terms of the following:
i. Current MI equation is not accepted widely to represent a variety of software applications.
ii. Current MI equation doesn't have well accepted benchmarks.
iii. Current MI equation is not widely used in the industry while developing or maintaining software applications.

In view of the foregoing, it has been found that conventional approaches to assess the software application maintainability suffer from shortcomings and inefficiencies that warrant improvement. Accordingly, there is a need for unique way to calculate the Maintainability Index of a software application based on several product quality parameters (PQM) and predict the maintainability of the software application.
BRIEF DESCRIPTION
A method for evaluating the maintenance effort of the software application is disclosed. The method includes identifying the list of process quality metric parameters (PQM parameters) that impact the maintainability of the software application, computing the values for the identified list of PQM parameters. The method further comprises determining the maintainability index (MI) of the software application and further evaluating the maintainability of the software application. The Maintainability Index for 95% of the software applications is in the range of 1 to 10. The software application can be either a JAVA class or a COBOL program. The threshold MI Value for JAVA Class and COBOL program is 3 and 5 respectively. The JAVA class requires less maintainability if the threshold MI value falls 3 or above on a scale of 1 to 10. The COBOL program requires less maintainability if the threshold MI value falls 5 or less on a scale of 10 to 1. Further, the MI of the software application is not comparable by their indices.
DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein;
FIG. 1 is a flow diagram illustrating a method for evaluating the maintenance effort of the software application, in one embodiment of the present technique;
FIG. 2 is a flow diagram illustrating a method for evaluating the maintainability of the software application coded in JAVA, in one embodiment of the present technique;

FIG. 3 is a flow diagram illustrating a method for method for evaluating the maintainability of the software application coded in COBOL, in one embodiment of the present technique; and
FIG. 4 is a system illustrating a generalized computer network arrangement, in one embodiment of the present technique.
DETAILED DESCRIPTION
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention which is known to the inventors at the time of filing the patent application. Of course, many modifications and adaptations will be apparent to those skilled in the relevant arts in view of the following description in view of the accompanying drawings and the appended claims. While the method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, depending on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragraphs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.
The invention relates generally to maintainability of software applications, specifically a method to predict the maintainability of a software application coded in Java or COBOL,
Referring now to figures, FIG. 1 is a flow diagram depicting a method to evaluate the maintenance effort of the software application, The method starts in step 100, wherein a list of product quality metric parameters (hereinafter, referred to as "PQM parameters") are identified for a given software application. The software application can be either coded in JAVA or COBOL, In one exemplary embodiment of the present invention, the PQM parameters for a software application are selected from a group of, but not limited, coupling between objects (CBO) or highest method cyclometric complexity (CC) or comment ratio (CR) or uncommented lines of code (LOC) or number

of attributes (NOA) or number of added methods (NOAM) or response for class (RFC) or percentage of comment in the code or total number of input/output operations in code or number of databases accessed in the code or total number of first level variable declared or total number of redefine clauses in code or measure of computational complexity (HALSTEAD) or cyclometric complexity (McCabe) or combinations thereof The software application can be either coded in JAVA or COBOL,
At step 102, the data for the identified PQM parameters for software application are computed. In step 104, the maintainability index (MI) of the software application is determined from the collected data of identified PQM parameters. For more than 95% of the software application programs, the MI value ranges from 1 to 10. At step 106, the maintenance effort of the software application is evaluated. In one exemplary embodiment of the present invention, the software application, irrespective of whether it is in development stage or in maintenance stage, is stated highly maintainable or less maintainable based on the MI value determined at step 104. In another exemplary embodiment of the present invention, the software application coded in JAVA is stated to be more maintainable if the computed MI is 3 or more on the scale of 1-10,
FIG. 2 is a schematic representation of a method used for evaluating the maintainability of the software application coded in JAVA wherein at step 200, the PQM parameters that impact the maintainability of the software program coded in JAVA are identified. In one exemplary embodiment of the present invention, the list of the PQM parameters is selected from the group of, but not limited, coupling between objects (CBO), highest method cyclometric complexity (CC), comment ratio (CR), uncommented lines of code (LOC), maximum number of parameters (MNOP), number of attributes (NOA), number of added methods (NOAM), response for class (RFC). In step 202, the data for the above PQM parameters is computed for a given software application program coded in JAVA.
In step 204, the Maintainability index (MI) of the software application coded in JAVA is determined by inputting the computed values for PQM parameters. In one exemplary embodiment of the present invention, the Ml for software application coded in JAVA is determined using the following formula:

M/ = 7.14-0.0266* CBO-0.00163* CC+ 0.00816* CR-0.000561 *LOC-0.196* MNOP - 0.0495 * NOA - 0.0405 * NOAM - 0.00852 * RFC
In the above equation, the coefficients are calculated by correlation analysis from the experimental data collected from sample software application coded in Java, The sample size of the software applications considered to fit the coefficients by regression analysis is approximately 1200. While doing the experimental analysis of the software application by experts, the following methodology is adopted:
i. Whenever a set of software applications consist of at least one program with a low maintainability, the set is assumed to be 'complex'. On the other hand, a set of programs is considered to be 'not complex' in case it does not have any program with a low maintainability.
ii. The average effort towards the modification of one line of code for each set is then found from randomly collected sets of programs
iii. Whenever the difference of the average effort is statistically significant, it may be construed that a cut-off point has been found. Sets of programs with maintainability lower than that indicated by the cut-off point are expected to require significantly higher effort for introducing one line of change compared to the set having a higher maintainability.
iv. As this method was carried out empirically, the limit for identification of Mow maintainability' was set arbitrarily starting with a very low maintainability value and repeating steps 1 and 2 while increasing this value. As soon as the difference of average effort becomes significant, a cut-off has been discovered and the computation may be stopped. This is the least stringent limit in the sense that this is the least maintainability that can be tolerated without increasing the average change effort per LOG significantly.
The MI value for 95% of the software applications coded JAVA is in the range of 1 to 10. At step 206, the MI is verified with the threshold value of 3 on the scale of 1 to 10. Upon verification, if the MI value is 3 or more, the software application coded in

JAVA is stated to be more maintainable (as shown in step 208), that is the code of the software application requires less maintenance effort to correct faults, improve performance or adapt to a changed environment. If the MI value falls below 3 on the scale of 1 to 10, then the software application coded in JAVA stated to be less maintainable (as shown in step 210), that is, the code of the software application is complex, that is the software application requires high maintenance effort to correct faults, improve performance or adapt to a changed environment. However, the above MI equation may not provide desired conclusions on the maintainability if the JAVA class has 2000 or more lines of code (LOC) or JAVA classes of type data access objects, value objects etc.
The maintainability of two software applications coded in JAVA (e.g. JAVA class A and JAVA Class B) is not comparable based on their MI indices. For e.g., if the MI of the JAVA class A is 3 and of another JAVA class B is 6, it doesn't state that JAVA class B is twice as maintainable as JAVA class A. But this indicates that JAVA class B is much more maintainable than JAVA class A.
FIG, 3 is a schematic representation of a method used for evaluating the maintainability of the software application coded in COBOL wherein at step 300, the PQM parameters that impact the maintainability of the software program coded in COBOL are identified. In one exemplary embodiment of the present invention, the list of the PQM parameters is selected from the group of, but not limited, percentage of comment in the code, total number of input/output operations in code, number of databases accessed in the code, total number of first level variable declared, total number of redefine clauses in code, measure of computational complexity (HALSTEAD) and cyclometric complexity (McCabe). In one exemplary embodiment of the present invention, the list of PQM parameters for a COBOL batch program is selected from the group of, but not limited, percentage of comment in the code, total number of input/output operations in code, measure of computational complexity (HALSTEAD) and cyclometric complexity (McCabe). In another exemplary embodiment of the present invention, the list of PQM parameters for a COBOL online program is selected from the group of, but not limited, percentage of comment in the code, total number of input/output operations in code, number of databases accessed in the code, total number

of first level variable declared, total number of redefine clauses in code, uncommented lines of code (LOC), measure of computational complexity (HALSTEAD) and cyclometric complexity (McCabe). In step 302, the data for the above PQM parameters is computed for a given software application program coded in COBOL.
In step 304, the Maintainability index (MI) of the software application coded in COBOL is determined by inputting the computed values for PQM parameters. In one exemplary embodiment of the present invention, the MI for COBOL batch program is determined using the following formula:
MI = - 2.64 + (0,104 * %COMMENTS) + (0.00235 * #of I/O * # of I/O Types)
- (2.98* Log(McCabe)) + (3.95 * Log (Halstead))
In another exemplary embodiment of the present invention, the MI for COBOL online program is calculated using the following formula:
MI = ^ 475 + (2.75 * Log (Halstead)) + (1.96 * Log (McCabe)) - (0.000338 * LOG)
- (0,628*#of DB) - (0.0177 * # of 01 Variables)- (0.0295 * # of Redefines)
+ (0.000260 * # of 01 Variables *# of Redefines) + (0.0132 * # of I/O)
Wherein
% Comments = % comment in the code
# of I/O = total no of I/O operations in code
# of DB = no of databases accessed in the code LOC = Lines of code (uncommented)
# of 01 variable = Total no of 01 (first level) variable declared
# of redefines = total no of redefine clauses in code Halstead = Measure of computational complexity McCabe = Cyclometric complexity
In the above equations, the coefficients are calculated by correlation analysis from the experimental data collected from sample software application coded in COBOL. The MI value for 95% of the software applications coded in COBOL is in the range of 10 to 1. At step 306, the MI is verified with the threshold value of 5 on the scale of 1 to 10. Upon verification, if the MI value is 5 or less, the software application coded in COBOL

is stated to be more maintainable (as shown in step 308), that is, the software application coded in COBOL requires less maintenance effort to correct faults, improve performance or adapt to a changed environment. If the MI value falls above 5 on the scale of 1 to 10, then the software application coded in COBOL stated to be less maintainable (as shown in step 210), that is, the code of the software application is complex, i.e., the software application requires high maintenance effort to correct faults, improve performance or adapt to a changed environment,
Further, the maintainability of the software application is not comparable in terms of indices. In one exemplary embodiment of the present invention, the maintainability of two software applications coded in COBOL (e.g. COBOL program A and COBOL program B) is not comparable based on their MI indices, For e.g., if the MI of the COBOL program A is 2 and of another COBOL program B is 4, it doesn't state that COBOL program A is twice as maintainable as COBOL program B, rather it indicates that COBOL program A is much more maintainable than COBOL program B.
The formulas used for computing MI of the software applications has muhiple applications from an organization point of view:
i. Organization can get insight to maintainability of an application being developed either internally or by a vendor using Maintainability Index and can proactively take steps to control maintenance cost/effort.
ii. Organization will be able to reduce the total cost of ownership and significant reductions in maintenance costs by maintaining program code more maintainable.
iii. Organization can use the Maintainability Index while transferring/ taking over the maintenance function to/from another vendor
iv. Organization can use MI to identify those parts of software application which are hard to maintain/ consumes significant time and effort to maintain for re-engineering/ modification

V. Organization can use MI to compare/ benchmark software application with similar/ competitive software applications.
Exemplary Computing Environment
One or more of the above-described techniques may be implemented in or involve one or more computer systems, FIG. 4 illustrates a generalized example of a computing environment 400. The computing environment 400 is not intended to suggest any limitation as to scope of use or functionality of described embodiments.
With reference to FIG. 4, the computing environment 400 includes at least one processing unit 402 and memory 404. In FIG. 3, this most basic configuration 406 is included within a dashed line. The processing unit 402 executes computer-executable instructions and may be a real or a virtual processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory 404 may be volatile memory (e.g., registers, cache, RAM), non¬volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. In some embodiments, the memory 404 stores software 416 implementing described techniques,
A computing environment may have additional features. For example, the computing environment 400 includes storage 408, one or more input devices 410, one or more output devices 412, and one or more communication connections 414. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 400. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 400, and coordinates activities of the components of the computing environment 400.
The storage 408 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which may be used to store information and which may be accessed within the computing environment 400. In some embodiments, the storage 340 stores instructions for the software 416.

The input device(s) 410 may be a touch input device such as a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scarming device, a digital camera, or another device that provides input to the computing environment 400. The output device(s) 412 may be a display, printer, speaker, or another device that provides output from the computing environment 400.
The communication connection(s) 414 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
Implementations may be described in the general context of computer-readable media. Computer-readable media are any available media that may be accessed within a computing environment. By way of example, and not limitation, within the computing environment 400, computer-readable media include memory 404, storage 408, communication media, and combinations of any of the above.
Having described and illustrated the principles of our invention with reference to described embodiments, it will be recognized that the described embodiments may be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computing environment, unless indicated otherwise. Various types of general purpose or specialized computing environments may be used with or perform operations in accordance with the teachings described herein. Elements of the described embodiments shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to which the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.

We Claim:-
1. A method for predicting maintainability of a software application,
comprising the steps of:
identifying a plurality of product quality metric parameters for the software application;
computing product quality metric parameter data for each of the plurality of product quality metric parameters of the software application;
determining a maintainability index of the software application from the product metric parameter data; and
evaluating the maintenance effort of the software application in response to the maintainability index, wherein the maintainability index is within a predefined range.
2. The method of claim 1, wherein the software application is selected from a group of software application coded in JAVA, software application coded in COBOL.
3. The method of claim 1, wherein the plurality of product quality metric parameters for the software application are selected from a group of coupling between objects (CBO) or highest method cyclometric complexity (CC) or comment ratio (CR) or uncommented lines of code (LOC) or number of attributes (NOA) or number of added methods (NOAM) or response for class (RFC) or percentage of comment in the code or total number of input/output operations in code or number of databases accessed in the code or total number of first level variable declared or total number of redefine clauses in code or measure of computational complexity (HALSTEAD) or cyclometric complexity (McCabe) or combinations thereof
4. The method of claim 1, wherein the plurality of product quality metric parameter data is indicative of at least one weight.

5. The method of claim 1, wherein for 95% percent of JAVA classes, the range for the maintainability index of the software application coded in JAVA is in the range of 1 to 10.
6. The method of claim 1, wherein for 95% percent of COBOL programs the range for the maintainability index of the software application coded in COBOL is in the range of 10 to 1.
7. A method for predicting maintainability of a software application coded in JAVA, comprising the steps of:
identifying a plurality of product quality metric parameters for the software application coded in Java class from the group of coupling between objects (CBO), highest method cyclometric complexity (CC), comment ratio (CR), uncommented lines of code (LOC), maximum number of parameters (MNOP), number of attributes (NOA), number of added methods (NOAM), response for class (RFC);
computing product quality metric parameter data of the software application coded in JAVA;
determining a maintainability index of the software application coded in JAVA from the product metric parameter data; and
evaluating the maintenance effort of the software application coded in JAVA in response to the maintainability index not exceeding a predefined range.
8. The method of claim 7, wherein the software application coded in JAVA requires less maintenance effort if the maintainability index is 3 or more.
9. A method for predicting maintainability of a software application coded in COBOL, comprising the steps of:
identifying a list of product quality metric parameters for the software application coded in COBOL from the group of percentage of comment in the code, total number of input/output operations in code, number of databases accessed in the code, total number of first level variable declared, total number of redefine clauses in code,

measure of computational complexity (HALSTEAD) and cyclometric complexity (McCabe);
computing product quality metric parameter data of the software application coded in COBOL;
determining a maintainability index of the software application coded in COBOL from the product metric parameter data; and
evaluating the maintenance effort of the software application coded in COBOL in response to the maintainability index not exceeding a predefined range.
10. The method of claim 9, wherein the software application coded in COBOL requires less maintenance effort if the maintainability index is 5 or less.
n. A computer program product comprising a computer usable medium having a computer readable program code embodied therein for evaluating a maintenance effort of a software application, the method comprising:
program code adapted for identifying a plurality of product quality metric parameters for the software application;
program code adapted for computing product quality metric parameter data for each of the pluraHty of product quality metric parameters of the software application;
program code adapted for determining a maintainability index of the software application from the product metric parameter data; and
program code adapted for predicting maintainability of the software application in response to the maintainability index, wherein the maintainability index is within a predefined range.

Documents

Application Documents

# Name Date
1 878-CHE-2008 FORM-13 12-01-2011.pdf 2011-01-12
1 878-che-2008-abstract.pdf 2011-09-03
2 878-che-2008-claims.pdf 2011-09-03
2 878-CHE-2008 FORM-13 12-01-2011.pdf 2011-01-12
3 878-che-2008-correspondnece-others.pdf 2011-09-03
3 878-che-2008 form-1 12-01-2011.pdf 2011-01-12
4 878-che-2008-description(complete).pdf 2011-09-03
4 878-CHE-2008 POWER OF ATTORNEY 12-01-2011.pdf 2011-01-12
5 878-che-2008-drawings.pdf 2011-09-03
5 878-che-2008-form 5.pdf 2011-09-03
6 878-che-2008-form 1.pdf 2011-09-03
6 878-che-2008-form 3.pdf 2011-09-03
7 878-che-2008-form 1.pdf 2011-09-03
7 878-che-2008-form 3.pdf 2011-09-03
8 878-che-2008-drawings.pdf 2011-09-03
8 878-che-2008-form 5.pdf 2011-09-03
9 878-CHE-2008 POWER OF ATTORNEY 12-01-2011.pdf 2011-01-12
9 878-che-2008-description(complete).pdf 2011-09-03
10 878-che-2008-correspondnece-others.pdf 2011-09-03
10 878-che-2008 form-1 12-01-2011.pdf 2011-01-12
11 878-che-2008-claims.pdf 2011-09-03
11 878-CHE-2008 FORM-13 12-01-2011.pdf 2011-01-12
12 878-che-2008-abstract.pdf 2011-09-03
12 878-CHE-2008 FORM-13 12-01-2011.pdf 2011-01-12