Software Development Guidelines Based on Fuzzy Decision-Making

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

Software Development Guidelines based on Fuzzy Decision-Making for Health care Applications Elisabetta Ronchieri INFN CNAF [email protected]

Valerio Venturi INFN CNAF [email protected]

ƒ

Abstract Software development of applications, regarding also health care, must deal with the needs of developers with different background. Incorporating the voice of developers, most often shared geographically, into the various phases of the software life cycle is becoming always and always important. Therefore, decision-making process is a valid way for translating software development needs into relevant guidelines to drive developers during their activity in order to obtain a maximum portability, extensibility and maintainability of software itself. The process takes into account multiple preferences and different tools in order to guarantee a certain freedom to developers making software development easy to achieve. In this research, we define a fuzzy decision-making algorithm for software development guidelines. The algorithm contributes defining a set of guidelines, a set of goals, a cost function for guidelines, and a set of constraints. A fuzzy operator is used to aggregate goals and constraints. This algorithm was tested using realistic software development case studies applied to an health care application.

1. Introduction Decision-making is a key in every part of a developer’s life to aim the definition, setting up and configuration of software. It consists of finding the best option from a feasible set. As a developer, you have to use your knowledge to make the best decisions you can make, weighting the positives and negatives of each option and considering all the alternatives. Some developers find that this process can be helpful in making their decisions and determining which option is the best of a given situation. In literature there are several methods for making better decisions. One of which is based on the sevenstep formula of the Josephson Institute of Ethics [22] applicable to developers as follows:

ƒ ƒ ƒ ƒ

ƒ ƒ

Cristina Vistoli INFN CNAF [email protected]

stop, whatever is going on or you are doing, and think, about the future and how your decision will affect your software later; clarify software goals to know exactly where you are going with the decision you are trying to make; determine results considering what you know and figuring out what you need to know; develop some options selecting package versions, identifying build tools and version control systems; consider the consequences of your options and of the decision itself, identifying parts of your code that will be affected by the options or the decisions and how they will be affected; make your decision; monitor your decision and modify it if you are sure that what you made was wrong.

Another method [23] offers different techniques for decision-making such as prioritizing your decisions, evaluating which option is more important and deciding if a decision is worth making. During software life cycle, it is crucial to guarantee the software quality and to reduce the development time and cost. Unfortunately software development deals with the uncertainty and vagueness from subjective perception and experience of developers in decision process. In the last decade, uncertainty is associated with decision-making research [18] that tries to sufficiently reduce uncertainty and doubt about alternatives to allow a reasonable choice to be made among them. Vagueness is mostly a problem of language, but it is not the main problem [31]. The objective of this research is to use a decision-making algorithm based on fuzzy set theory [32] to evaluate the selection process and to choose the best alternative from available alternatives. Fuzzy set theory incorporates human intelligence in decision-making models. It is used to represent the evaluation results [24], mainly because information is subjective, imprecise and expressed in a nature language by individual developers. By using fuzzy set theory,

978-0-7695-3869-3/10 $26.00 © 2010 IEEE

1

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

decision problems can be represented mathematically as an optimization problem. Fuzzy set theory provides a flexible framework, in which it is possible to satisfactorily solve many of the obstacles of lack of prevision. Fuzzy set theory represents the qualitative aspects in qualitative terms (i.e., linguistic terms) by means of linguistic variables, whose values are words or sentences in a natural or artificial language. In general, the use of words or sentences is a more direct, flexible and realistic form to express the qualitative aspects [8, 11, 12, 19]. However, there are situations, in which the framework is heterogeneous, i.e., the information is not equally important [10, 14, 20, 21]. For example, in the case of a group of developers expressing their opinion on the possible solution of a given problem, two aspects have to be modeled: 1) their decision must not be considered with equal relevance, given that, there will be developers with more experience than others, and therefore, all the opinions shall not be equally reliable; and 2) a final and global decision must be made using the initial and individual decision. The first aspect is modeled by assigning a weight to each developer. The weights may be interpreted in at least two different ways [14, 15]: 1. 2.

each developer is viewed as a sub-group and the weight reflects the relative size of this subgroup; the weight may reflect the relevance of the developers in the group.

The second aspect is dealt with the usage of adequate operators for combining information before reaching a final decision, usually called information aggregation operators. Health care systems, ranging from pharmaceutical research, medical imaging and drug development system, make use of applications to deliver health care to human community. Developers involved in the development of these applications need to face challenges related to compliance, cost effectiveness, and quality requirements to assure the application success in health care. Therefore, they have to use processes to conceive, design and develop health care applications, and to perform checks and control features to satisfy the specified requirements. Health care organizations have acknowledged the need for defining and implementing standards and processes [25]. For engineering the software, developers of health care applications, as developers of other applications in further domains, need to follow processes that are usually structured in several steps, for example related to the analysis of requirements, design, coding, testing, and configuration management

[29], which strongly influence the success of the software project. Each step addresses specific needs and identifies a set of guidelines. This paper proposes a generic algorithm that selects one guideline at time and only executes the described guidelines. This algorithm has been formulated having in mind two case studies identified from the experience of working with new infrastructures and software projects during their migration to ETICS (eInfrastructure for Testing, Integration and Configuration of Software) [4, 5]. The first case study aims to describe the usage and setting up of ETICS according to the special needs of an infrastructure. The second case study, instead, aims to collect guidelines related to the well-defined configuration and maintenance of software projects in order to facilitate the adoption of ETICS. However, some guidelines are always valid, not strictly related to the usage of ETICS itself, like the analyzing of the software structure, software dependencies, software versioning and software portability. In the latest three years, ETICS made experiences to estimate automatically software quality attributes like interoperability, portability, standardization and compliance: in particular, the interoperability verification between different standard implementation of DICOM (Digital Imaging and Communications in Medicine) was proved in [3, 13, 30]. Due to this activity, dicom4j (digital imaging and communications in medicine 4 java)1 is the health care application used to illustrate how the algorithm can be applied to this kind of applications. This paper is organized as follows. In Section 2 an algorithm based on fuzzy decision-making adopted in this research is illustrated. Section 3 introduces a case study on a software development. Section 4 describes the health care application to which the algorithm has been applied, while Section 5 presents some results obtained by simulating the proposed algorithm. Finally Section 6 draws some conclusions.

2. Fuzzy decision-making algorithm Fuzzy decision-making is proposed to deal with non-probabilistic uncertainty and vagueness in the environment in which the decision-making takes place. Goals of the decisions and imposed constraints represent two important elements of decision-making: Goals of the decisions are represented by the maximized objective function; Imposed constraints confine the decision space.

1

Welcome to dicom4j, http://dicom4j.sourceforge.net/.

2

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

Fuzzy decision-making replaces the goals and the constraints with their fuzzy equivalents [32, 6]. In this section the usage of fuzzy decision-making to obtain an optimal decision in software development is described. The guideline that better satisfies the goals and constraints of the system is the optimal. The decision is often formulated as a quintuple (A, Θ, Ξ, k, D) [17], where: ƒ ƒ ƒ ƒ

ƒ

A is the set of alternatives (i.e., guidelines); Θ is the set of the states of the environment in which the decision is taking place; Ξ is the set of consequences that results from the choice of a guideline; k maps AxΘ → Ξ , specifying a resulting consequence for each element of the set of environment states Θ and each element of the set of alternatives A; D is the decision function defined as D : Ξ → R , reflecting the preference structure and incorporating the goals of the decision maker.

D induces a preference ordering on the set of consequences Ξ such that

ε i ; ε j if and only if D(ε i ) > D(ε j ) where ε i ,

εj∈

expressing

that

consequence

εj.

(1)

; is the preference relation

Ξ and

consequence

ε i is

preferred

to

ri (o j ) is the cost of rule i for guideline g, and

states

o1 ,.., om represents all states relevant for the

guideline g. The cost of rule i can be expressed as

ri = wi d i (o j )

(3)

where wi is a constant factor, and

d i (o j ) is an

activation level for rule i operating in fuzzy state o j ∈Θ with j=1,..,m. When all rules of guideline g have an activation level tending to zero (i.e., the guideline g is inactive), also the cost for this guideline will tend to zero: n

if

∑d

→ 0 , f ( g , o1 ,.., om ) → 0

i

(4)

i =1

In the case of an inactive guideline, a default rule described as follows needs to be added:

rn +1 = wn+1 d n +1 (o j ) where

(5)

wn +1 is the value to which the cost function

must tend when the activation level of the other rules tend to zero. The value d n +1 can be computed as follows: n,m

The following definitions are fundamental to describe fuzzy decision-making algorithm. For a better understanding of the algorithm, G, which stands for guidelines, takes the place of A in the quintuple.

2.1. Cost function Let G be a given set of possible guidelines, which contains a solution to a decision-making problem. Let Θ be the set of the states of the environment in which the decision is taking place. A cost function f can be defined as follows, associating for each guideline-states pair a consequence with g∈G and o1 ,.., om ∈Θ :

f ( g , o1 ,.., o m ) =

where

n ,m

∑ r (o i

i , j =1

j

)

(2)

d n +1 (o j ) = 1 − ∑ d i (o j )

(6)

j ,i =1

Each fuzzy state is represented by a linguistic term. The activation level of a rule i, i.e., d i (o j ) , can be considered as a predicate defined by a fuzzy aggregation operator over linguistic terms [16]. Predicates can be defined over a tree, considering root tree as a fuzzy aggregation operator, and tree leafs as fuzzy states using linguistic term.

2.2. Fuzzy goals Let G be a given set of possible guidelines which contains a solution to a decision-making problem. Let Θ be the set of the states of the environment in which the decision is taking place. A fuzzy goal GO is a fuzzy set on f characterized by the membership function μ GO ( f ( g , o1 ,.., o m )) .

3

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

It represents a maximum preference level for each guideline g∈G in states o1 ,.., om ∈Θ.

g * = arg max[μ F ( g , o1 ,.., om )]

2.3. Fuzzy constraints

with g∈G and

Let G be a given set of possible guidelines which contains a solution to a decision-making problem. A fuzzy constraint C is a fuzzy set on G characterized by the following membership function:

satisfies the goals and the constraints. In the case of two or more guidelines with the same satisfaction level, the decision can be made by a default rule, establishing priorities between guidelines. To reduce the complexity involved in decision-making, guidelines are decomposed in sub-guidelines.

μ C ( g ) = G → [0,1] The

function

μ C (g )

(7) establishes

a

maximum

(9)

g∈G

o1 ,.., om ∈Θ. It is the one that better

3. Case study on software development

preference level for each guideline g∈G. A set of constraints represent software development issues that developers must deal with. They represent a specific environment in where developers work. They are pieces of information extracted from the environment to contextualize the software development process.

During software development developers have to take several decisions related to the configuration, deployment and maintenance of software. Under this scenario, there are several guidelines representing an ideal case study to test fuzzy decision-making. The objective of this research is to implement an algorithm to assist developers in selecting a proper set of guidelines in software development.

2.4. Fuzzy decision

3.1. Problem description

Let G be a given set of possible guidelines which contains a solution to a decision-making problem. Let GO be the set of fuzzy goals for the decision, represented by the membership function μ GO ( f ( g , o1 ,.., o m )) , with g∈G and

In this case study, a software health care application, called dicom4j, that needs to well define software configuration, to maintain software projects, and to deploy and test software is taken into consideration. This software application presents the same issues that, for our experience, have software projects during their migration into ETICS used to build, configure, deploy and test software. In particular, ETICS provides a service to help software developers but also managers and users, to better manage complexity and improve the quality of their software. During software migration to ETICS, some guidelines that should be adopted by developers have been identified. These guidelines start from two cases: 1) the deployment of the ETICS services, and 2) the development of software application. In this research only guidelines related to the second case have been considered.

o1 ,.., om ∈Θ. Let C be the set of constraints represented by the membership function μ C (g ) , with g∈G. Then, the fuzzy decision F is given by the intersection of the fuzzy goals GO and the fuzzy constraints C, represented by the following membership function μ F ( g , o1 ,.., o m ) with g∈G and

o1 ,.., om ∈Θ:

μ F ( g , o1 ,.., om ) = = μGO ( f ( g , o1 ,.., om )) ∧ μC ( g ) = (8) = min (μGO ( f ( g , o1 ,.., om )), μC ( g ) ) 2.5. Optimal fuzzy decision The optimal fuzzy decision maximizing decision and defined by

g * is called the

3.1.1. Software development guidelines. The most important guidelines are specified in the following set: File software structure that expresses the structure of the software design: it recommends putting files that are associated with a module and work together in the same directory. Code software structure that shows the structure of the software design: it recommends producing consistent, clear code and following the

4

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

conventions of the adopted programming language. Software portability that expresses the possibility of using a defined platform to build a given module. Software dependency that shows the necessity of avoiding conflicts and recursive dependencies inside a software application. Software versioning that keeps track of different versions of a piece of software. Build software tool that represents the process of compiling source code. Software packaging that expresses the possibility of creating distribution packages on supported platforms in different formats. These guidelines also match some of the steps [29], like coding and configuration management, that structure engineering processes, followed by developers of health care applications to success the software project in health care. In literature [33], there are several kinds of structures associated with a software product. In this paper, only file and code software structures have been considered. The process of compiling source code considers several factors, such as the adoption of Version Control Systems (VCSs) to maintain their code, and of compile tools to build and test their code. The most common VCSs are SubVersion [26] and Concurrent Version System (CVS) [28, 7]. Tools to build and test code are for example ant [34] and autotool [35]. 3.1.2. The set of environment states. States result from experiences performed into ETICS and literature [29, 33]. File software structure guideline specifies files as environment states, which are recommended to be included into the directory of a module. Code software structure guideline provides directories, which are recommended to be included into the directory of a module. Software dependency guideline specifies a specific version of a software package, and identifies when that version is required. Software versioning guideline provides for the environment states two different version schemas [1], in which there are the following numbers: major is the number increased when there are significant changes in functionality; minor is the number incremented when only minor features or backward compatible fixes have been added; revision is the number incremented when bugs are fixed; and age is the number incremented when the build or test process has been fixed and updated. Software packaging guideline expresses two formats of distributed packages: rpm [2] and tar [27].

According to the list of the presented guidelines the following set of states is used, grouped for guideline: File software structure guideline ƒ readme file describing the module and its use; ƒ status file listing what is finished and what needs to be done; ƒ install file explaining how to install the module; ƒ maintenance file explaining how to maintain the module files; ƒ license file containing license module information. Code software structure guideline ƒ src directory containing source code; ƒ interface directory containing public interface files such as files with suffixes .h or .wsdl; ƒ config directory containing configuration and scripting files such as files with suffixes .conf, .sh, and .csh. Software portability guideline ƒ slc4 platform; ƒ sl5 platform. Software dependency guideline ƒ run time dependency used during software installation and execution; ƒ build time dependency used during software compilation; ƒ build and run time dependency used both for compiling software and for installing and executing software; ƒ version A of library B; ƒ version C of library B. Software versioning guideline ƒ major, minor, revision, age describing a version composed by four numbers; ƒ major, minor describing a version composed by two numbers. Build software tool guideline ƒ subversion used as VCS; ƒ cvs used as VCS; ƒ ant for java programming language used as build tool; ƒ maven for java programming language used as build tool; ƒ autotool for the all programming languages used as build tool. Software packaging guideline ƒ rpm package used on Unix operating system; ƒ tar package used on Unix operating system. Each state is represented by a linguistic term, which provides a more natural way to express the

5

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

rating for assessing candidate guidelines. In this paper we adopt a linguistic scale consisting of seven linguistic values [36]: 1) ‘Definitely Not’ (DN), 2) ‘Probably Not’ (PN), 3) ‘Maybe Not’ (MN), 4) ‘Unknown’ (U), 5) ‘Maybe’ (M), 6) ‘Probably’ (P), and 7) ‘Definitely’ (DE). The highest linguistic value is DE, while the lowest one is ‘DN’. 3.1.3. Main goal of developers. The main goal of developers is to take as few goals as possible. This linguistic term can be defined by the membership

[ ]

function μ ( y ) : R → 0,1 from the real line R to the close interval [0, 1], where y is the number of taken goals. 1

1

3.1.4. Cost function of software development. For simplicity, only two guidelines, identified by file software structure and code software structure, are described. The algorithm is able to consider seven guidelines. The number of taken goals depends on the guideline that is under evaluation. Each guideline is represented by one or more rules. The highest priority is given to the guideline that has the minimum value. Each rule has a cost that contributes to the total cost. The rule cost is determined by the product between its constant cost w and its activation level d given by a predicate. Each guideline has a default rule with cost 10, such that its activation level is given by n ,m ⎞ ⎛ max⎜⎜ 0.1 − ∑ d i (o j ) ⎟⎟ j ,i =1 ⎠ ⎝

where

(11)

d i (o j ) represents rule i activation level for

guideline g operating in fuzzy state

o j ∈Θ with

j=1,..,m. The value of the constant cost w is defined by expertise knowledge, reflecting the answer to questions like: what average goals the software development takes if developers consider guideline g in states o1 ,.., om ∈Θ ?; or what must be the average number of taken goals when developers execute software dependency guideline in states o1 ,.., om ∈Θ ? The expertise knowledge states that this cost must be low. 3.1.5. Constraints of software development. A maximum satisfaction level is assigned to each guideline via constraints. Examples of constraints are: coding style and making code simpler cannot be applied, therefore the code software structure guideline should not be active; dependency conflicts inside a

software application cannot be avoided during software installation, therefore the software dependency guideline should not be active. When a guideline is not activated its fuzzy value is 0, but fuzzy values for other guidelines can be set to 1. 3.1.6. Fuzzy decision-making applied to software development. The decision of what is the best guideline to select is made by evaluating all the guidelines, using the cost function and main goal function. The selected guideline has the maximum satisfaction level for the goal and the constraints. The fuzzy operator min is used to constrain the satisfaction level of goal with the maximum level allowed by constraints. Priorities between guidelines are expressed by the following linguistic scale consisting of five linguistic values: 1) ‘Fully Not’ (FN), 2) ‘Slightly Not’ (SN), 3) ‘Medium’ (M), 4) ‘Slightly’ (S), 5) ‘Fully’ (F). The highest linguistic value is ‘Fully’, while the lowest one is ‘Fully Not’. The following membership functions express the evaluation of the linguistic values:

⎧b − y ⎪

μ FN ( y ) = ⎨ b − a

⎪⎩ 0 ⎧y−a ⎪b − a ⎪⎪ c − y μ SN ( y ) = ⎨ ⎪c −b ⎪ 0 ⎪⎩ ⎧ y −b ⎪c−b ⎪⎪ d − y μ M ( y) = ⎨ ⎪d −c ⎪ 0 ⎪⎩ ⎧y−c ⎪d − c ⎪⎪ e − y μS (y) = ⎨ ⎪e − d ⎪ 0 ⎪⎩ ⎧y−d ⎪ μF (y) = ⎨ e − d ⎪⎩ 0

if

a≤ y≤b

if

y>b

if

a≤ y≤b

if

b≤ y≤c otherwise

if

b≤ y≤c

if

c≤ y≤d

(10)

otherwise if

c≤ y≤d

if

d ≤ y≤e otherwise

if

d ≤ y≤e

if

y>e

6

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

where a, b, c, d, e ∈[0,1], a < b < c < d < e, a and e stand for the lower and upper value of the fuzzy number.

Figure 3 depicts the formulation of the decision problem for code software structure guideline. The set of the environment states are defined by:

3.2. Guideline detection

Θ={src directory DN, src directory PN, src directory MN, src directory U, src directory M, src directory P, src directory DE, interface directory DN, interface directory PN, interface directory MN, interface directory U, interface directory M, interface directory P, interface directory DE, config directory DN, config directory PN, config directory MN, config directory U, config directory M, config directory P, config directory DE},

This section describes how a given guideline is detected. Figure 2 shows the guideline selection process, which must be applied to all software development guidelines. Step 0: Provide a set of environment states Step 1: Evaluate environment states by a group of developers Step 2: Rank environment states by the group decision making model Step 3: Determine consensus by using weights Step 4: Is consensus reached? Step 4.1: If not, Step 1 Step 5: Select guideline Figure 2. The decision process to select guideline.

interface dir DE src dir DE

Code Software Structure

D1

Fully

while the set of guidelines is defined by: G={code software structure}. The solution space of G x Θ has twenty-one elements. The mapping k associates for each guidelinestates pair a consequence, like the three consequences specified below: -

-

config dir DE

interface dir U src dir DE

Code Software Structure Slightly

config dir U

D2

if src directory, interface directory and config directory are DE and code software structure is set, the guideline code software structure is fully accepted; if src directory is DE, interface and config directories are U, and code software structure is set, the guideline code software structure is slightly accepted; if src directory, interface directory, and config directory are DN, and code software structure is set, the guideline code software structure is not accepted.

The decision function D maps the consequences to real numbers D1 , D2 , and D21 , which impose a preference ordering on the solution set. Therefore, the *

interface dir DN src dir DN

Code Software Structure

Fully Not

Figure 4 depicts the formulation of the decision problem for file software structure guideline. Considering what detailed for code software structure guideline, the best choice for file software structure

D21

config dir DN states

best choice for code software structure guideline g is given when developers agree on the following states: src, interface and config directories have to be included in the software structure tree.

guidelines Set of solutions

Preference ordering

Figure 3. Graphical representation of a choice calculation for code software structure guideline: in the top the best choice is given.

*

guideline g is given when all its environment states, like readme file, status file, install file, maintenance file, and licence file are chosen by developers. For this guideline the solution space of G x Θ has thirty-five elements.

7

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

readme file DE status file DE istall file DE mintenance file DE license file DE

interface dir U src dir DE

header, Store Service Class User (SCU) to perform storage request, Worklist SCU to perform basic modality worklist request. File Software Structure

4.1. Adoption of guideline selection process

File Software Structure Slightly

config dir U

readme file DN File Software status file DN install file DN Structure maintenance file DN license file DN states

D1

Fully

D2

Fully Not

D35

guidelines Set of solutions

Preference ordering

Figure 4. Graphical representation of a choice calculation for file software structure guideline: in the top the best choice is given.

4. Used health care application As health care application we have decided to use dicom4j. It is a software project with the aim to provide java source code related to the Digital Imaging and Communications in Medicine (DICOM) Standard2. The source code is in pure java making software portability easier working on all operating systems. This project presents typical issues of software development, having to answer different needs of DICOM software developers. For example, by provisioning a DICOM framework, which implements the standards, the process of software validation can be improved. In addition, a toolkit to develop software based on this framework can facilitate the adoption of DICOM standard and the development of DICOM applications [9], like DICOM Editor to view a dicom

In the case of dicom4j, the guideline selection process has been applied to select the software portability guideline and build software tool guideline as described in Figure 5 and Figure 6 respectively. Figure 5 shows that the consensus is achieved with a medium value, when developers evaluate sl4 platform state as DE and sl5 platform state as U. Figure 6 details that the consensus is achieved with a high value, when developers evaluate subversion state as DE, maven state as DE. Step 0: The environment states are: ƒ slc4 platform ƒ sl5 platform Step 1: Developers evaluate environment states as follows: ƒ sl4 platform DE ƒ sl5 platform U Step 2: The model ranks environment states as ƒ slightly Step 3: The consensus is medium Step 4: Is consensus reached? Step 4.1: Yes Step 5: The guideline has been selected Figure 5. The decision process to select software portability guideline. Step 0: The environment states are: ƒ subversion ƒ maven Step 1: Developers evaluate environment states as follows: ƒ subversion DE ƒ maven U Step 2: The model ranks environment states as ƒ fully Step 3: The consensus is high Step 4: Is consensus reached? Step 4.1: Yes Step 5: The guideline has been selected Figure 6. The decision process to select build software tool guideline.

2

Digital Imaging and Communications in Medicine (DICOM), http://medical.nema.org/dicom/.

8

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

5. Simulation results

Software Editing - From Check Out To Commit Operations,” Journal of Physics: Conference Series, Vol. 119, No. 4, 2008.

We have implemented in python the case study. Some tests were executed. The selected software development guidelines were tested considering all possible states in order to evaluate the goodness of the script itself. When the algorithm is not near the best decision for a given guideline, it decides to change guideline. The algorithm runs in 200 µs over a Intel(R) Xeon(R) CPU E5410 @ 2.33GHz with seven guidelines. The code contains some optimisation and used python libraries that are quicker then specific code.

[5] Bégin, M.-E., P. Couvares, E. Ronchieri, A. Di Meglio, and E. Takacs, “ETICS: the international software engineering service for the grid,” Journal of Physics: Conference Series, Vol. 119, No. 4, 2008.

6. Conclusions This research developed a fuzzy decision-making algorithm to improve software development process through a set of guidelines and to effectively solve software evaluation process. Designing rules for fuzzy decision is very intuitive, as shown in an example concerning a subset of the software development guidelines. The algorithm includes a way of representing information about the issue that has to be coped with. In addition, it constructs relations among guidelines based on the concept of fuzzy and determines ranking orders among them. By using the algorithm, the ambiguities involved in the assessment data could be represented and processed to assure a more convincing and effective evaluation process. However, the main problem still continues to be the modus operandi of developers that usually are non-well inclined to accept changes.

References [1] Atwood, J., “Coding Horror: What's In a Version Number, Anyway?,” 2007, http://www.codinghorror.com/blog/archives/000793.html. [2] Bailey, E. C., http://www.rpm.org/max-rpm/.

“Maximum

RPM,”

[3] Bégin, M.-E., P. Couvares, G. Diez-Andino Sancho, S. Da Ronco, A. Di Meglio, L. Dini, P. Fabriani, B. Gietz, A. Pavlos, E. Ronchieri, M. Selmi, E. Takacs, and M. Zurek, “Analysis of Requirements for Automated Interoperability Testing,” In Proceedings of the INTEGRATED DESIGN AND PROCESSING TECHNOLOGY (IDPT 2007), Antalya, Turkey, 3rd - 8th June 2007. [4] Bégin, M.-E., S. Da Ronco, G. Diez-Andino Sancho, M. Gentilini, E. Ronchieri, and M. Selmi, “ETICS Meta-data

[6] Bellman, R. E., and L. A. Zadeh, “Decision-making in a fuzzy environment,” Management Science Series, Vol. 14, No. 4, pp. 141-164, December 1970. [7] Berliner, B., Proceedings of the USENIX Winter 1990 Technical Conference (Berkeley, CA: USENIX Association) pp. 341–352, 1990, citeseer.ist.psu.edu/berliner90cvs.html. [8] Bonissone, P. P., and K. S. Decker, “Selecting Uncertainty Calculi and Granularity: An Experiment in Tading-off Precision and Complexity,” Uncertainty in Artificial Intelligence, L. H. Kanl and J. K. Lemmer, Eds. London: North-Holland, 1986, pp. 217-247. [9] Brattheim, B., A. Landmark, P. Toussaint, and A. Faxvaag, “Extending PACS by adapting messaging for clinical practice: a case study related to after-EVAR followups,” International Journal of Computer Assisted Radioloy and Surgery, Vol. 4, Suppl 1, pp. 304-310, 2009. [10] Cholewa, W., “Aggregation of Fuzzy Opinions: An Axiomatic Approach,” Fuzzy Sets and Systems, Vol. 17, pp. 249-259, 1985. [11] Delgado, M., J. L. Verdegay, and M. A. Vila, “Linguistic Decision Making Models,” Int. J. Intelligent Systems, Vol. 7, pp. 479-492, 1993. [12] Delgado, M., J. L. Verdegay, and M. A. Vila, “A model for Incomplete and Vague Information in Decision Making Problems,” Int. J. Intelligent Systems, Vol. 9, pp. 365-378, 1994. [13] Dini, L., E. Ronchieri S. Da Ronco, G. Diez-Andino Sancho and M. Selmi, “Integrated Solutions for Information Sharing In Health Care Applications,” In Proceedings of the 41st Annual Hawaii International Conference on System Sciences, Waikoloa, HI, USA, 7-10 Jan, 2008. [14] Dubois, D., and J. L. Koning, “Social Choice Axioms for Fuzzy Set Aggregation,” Fuzzy Sets and Systems, Vol. 43, pp. 257-274, 1991. [15] Dubois, D., H. Prade, and C. Testemale, “Weighted Fuzzy Pattern Matching,” Fuzzy Sets and Systems, Vol. 28, pp. 313-331, 1988. [16] Dubois, D., and H. Prade, “A review of fuzzy set aggregation connectives,” Information Sciences, Vo. 36, pp. 85-121, 1985.

9

Proceedings of the 43rd Hawaii International Conference on System Sciences - 2010

[17] Grabish, M., H. T. Nguyen, and E. A. Walker, “Fundamentals of Uncertainty Calculi With Applications to Fuzzy Inference,” Elbert Walker, Springer, 1995. [18] Harris, R., “Introduction to Decision Making,” VirtualSalt., 1998, http://www.virtualsalt.com/crebook5.htm. [19] Herrera, F., E. Herrera-Viedma, and J. L. Verdgay, “A Sequential Selection Process in Group Decision Making with Linguistic Assessments,” Information Sciences, Vol. 85, pp. 223-239, 1985. [20] Herrera, F., E. Herrera-Viedma, and J. L. Verdegay, “A Model of Consensus in Group Decision Making under Linguistic Assessments,” Fuzzy Sets and Systems, Vol. 78, pp. 73-87, 1996.

[28] Purdy, G. N., “CVS Pocket Reference,” O’Reilly, 2000. [29] Ravishankar, N., “IT Applications for Health care: Leverage Processes for High Quality,” SETLabs Briefings, Infosys, September 2008. [30] Ronchieri, E., M.-E. Bégin, and M. C. Vistoli, “A STUDY OF MULTI-NODE MECHANISM TO INTEROPERABILITY ISSUE,” In Proceedings of INTEGRATED DESIGN AND PROCESSING TECHNOLOGY (IDPT 2008), Taichung, Taiwan, 1st 6th June 2008. [31] Russell, B., “Vagueness”, Australian Journal of Philosophy and Psychology, Vol. 1, pp. 84–92, 1923.

[21] Herrera, F., E. Herrera-Viedma, and J. L. Verdegay, “A Rational Consensus Model in Group Decision Making under Assessments,” Fuzzy Sets and Systems, 1996.

[32] Sousa, J. M. C., and U. Kaymak, “Fuzzy Decision Making in Modeling and Control,” World Scientific Series in Robotics and Intellignet Systems - Vol. 27, 2002.

[22] Josephson, M. S., “Making Ethical Decisions (Paperback),” Josephson Institute of Ethics, 2002 edition, March 2002. [23] Jonassen, D. H., “Modeling with Technology: Mindtools for Conceptual Change,” 3/E. Allyn & Bacon, 2006.

[33] Top, S., H.J. Nørgaard, B. Krogsgaard, and B.N. Jørgensen, “The Sandwich Code File Structure - An architectural support for software engineering in simulation based development of embedded control applications,” In Proceedings of the IASTED International Conference on Software Engineering (SE 2004), ACTA Press, 2004.

[24] Klir, G. J., and B. Yuan, “Fuzzy Sets and Fuzzy Logic: Theory and Applications,” Prentice-Hall, New Jersey, 1995.

[34] Tilly, J. E., and E. M. Burke, “Ant: The Definitive Guide”, O’Reilly Media, May 2002.

[25] Lovelock, J-D., “Dataquest Insight: Health care Industry Premier, 2006,” Gartner Research, April 2007.

[35] Vaughan, G. V., B. Elliston, T. Tromey, and I. L. Taylor, “GNU Autoconf, Automake and Libtool, ” New Riders, 2000.

[26] Mason, M., “Pragmatic Version Control Using Subversion [Illustrated] (Paperback),” Pragmatic Bookshelf, 2005. [27] McCarty, B., “Learning Debian GNU/LINUX,” O’Reilly Media, 1999.

[36] Wang, J., and Y.-L. Lin, “A fuzzy multicriteria group decision making approah to select configuration items for software development,” Fuzzy Sets and Systems, Vol. 134, pp. 243-363, 2002.

10