Amid Khatibi Bardsiri

Amid Khatibi Bardsiri


Amid received his BSc degree in Computer Software Enginering from Shahid Bahonar University in Kerman, Iran in 2008, and his MSc degree in Software Engineering from Islamic Azad University in Tehran, Iran in 2010. He is currently undertaking his PhD in the Science and Research branch of Islamic Azad University, focusing on software service metrics and measurement. He has published about 30 research papers in international journals and conference proceedings. His areas of research include software systems engineering, software service development, software service metrics, SOA, and cloud computing.


rss  subscribe to this author

Seyyed Mohsen Hashemi

Seyyed Mohsen Hashemi


Seyyed received his MSc degree in Computer Science from Amirkabir University of Technology (Tehran Polytechnic University) in 2003, and his PhD degree in Computer Science from the Azad University in 2009. Moreover, he is currently a faculty member at the Science and Research branch at Azad University in Tehran. His current research interests include Software Intensive Systems, E-X systems (E-Commerce, E-Government, E-Business, and so on), Global Village Services, Grid Computing, IBM SSME, Business Modeling, Agile Enterprise Architecting through ISRUP, and Globalization Governance through IT/IS Services.


rss  subscribe to this author


Development Effort Estimation Metrics Suite for Global Village Service Published: June 10, 2015 • Service Technology Magazine Issue XC PDF

Abstract: To achieve the Global Village Service (GVS) in form of a services foundation, web developers confront with information and services integration in the software development projects. Beside, unifying most of services from these types of projects could be realized for the global village with the headache of the upcoming techniques; particularly cloud computing, along with coming patterns, like globalization. Hence, developers require certain basis architectures to enhance the development of the electronic services structure according to an extensive method. GVS is often referenced as the baseline of any type of software service engineering activities related to the software services and globalization, along with the cloud computing aspects. Precise prediction of service development effort is a popular problem both in commerce and also for academia. The term effort is a significant and valuable parameter in development process and service management. The suitable calculation of effort assists the project managers to assign the sources well and also handle price and duration to ensure the project will be done in the decided budget and time. Nevertheless, there can be very few GVS metrics built to assess difficulty, effort estimates and status of GVS methods. This article consequently suggests a GVS metrics framework that has both service-level and GVS-wide metrics to determine effort of a GVS approach.

Keywords: Global Village Service, Effort Estimation, Metrics

1. Introduction

The global village is a phrase elaborated with Marshall McLuhan in 1962. McLuhan explains the way the entire world may be developed into a village by electrical technologies [REF-1]. Nowadays, the global village is usually employed as a metaphor to explain the world wide web and internet, while the expression 'Global Village' is popularized as residents of the globe, countries in the world, along with the world compared with a small village [REF-2]. In addition, computer software is actually shown up as the service in the global village, and it gives a vital part to the services in the system and software development projects. Therefore, a modified type from the future generation software services (known as Global Village Services) is actually needed to be as a plan in the system and software development projects. It is time to provide the description of the expression 'Software Engineering' (to Global Village Software Engineering) depending on the term of 'Service' (Global Village Service) [REF-3]. Consequently, the meaning of the phrase 'Software Services' has to be modified with priority of the upcoming trends and technologies. The baseline of definitions to the phrase "Software Engineering" is explained in IEEE in 1990 [REF-4] as: "Software engineering is the applying of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software." Seeing that the final meaning, it looks limited on the country and it has to be expanded to the world. However, IBM defines a service as a repeatable business task (e.g. open new account and check customer credit). Hashemi [REF-5] defines the phrase 'Global Village Service' rather than everyone to prevent each inconsistency. An abstract description to term 'Global Village Service', employed to any specific modeling in the overall of article, is proposed as follow: A Global Village Service is the fine-grained and full-grown, repeatable-sharable function includes the resources, which might be recognized via a variety of the Global Village Service actions to satisfy some Global Village Service actors. Using this priority of explanation, E-Government, E-Commerce, and E-Business services might be regarded to dance in a cloud-based choreography to appreciate the End-to-End Processes.

On schedule and plan decided delivery of service, is among the important concerns of the very most software organizations. The required effort to create a service are probably the most effective and important variables of a project so the approximation of this parameter is dissimilar because of the following three major causes [REF-6]:

  1. Numerous modifications in electronics world, requiring filling the gap between software and hardware.
  2. Many variations in client demands.
  3. High number of services and the existing competitive business in them.

Because the estimation method ought to be performed in the starting stages of the project, an efficient technique is required to be capable of work with little and initial information. It is apparent that both overestimates or underestimates result in source decrease and lead the organization situation into risk [REF-7].

Although GVS, similar to various service development-based methodologies, did not generate methods or metrics for calculating effort and cost of a service. This article consequently suggests an unique collection of metrics, designed especially to assess effort and cost of a service based solution.

2. Global Village Service

Global Village (GV) describes the integration of using electronic services that are providing by service providers around the world. GV claims to reduce communication costs and eliminate geographical restrictions via provisioning services on Internet [REF-1]. In the advent of advances technology, software industries are shifting from traditional software development to universal software development (outside the borders). The GV concentrates on aggregation of information and different resources as services to be used by users around the world. The last definition of software engineering extends the IEEE definitions" software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software" to term" global village software engineering "as the universal definition "Global village software engineering is the application and/or study of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, that has an impact on Global village services; that is application of engineering to software in the global village" [REF-2].

The motivation and challenges of global systems are depicted in Figure 1. In Global village, software engineering has different challenges that affect software development processes (SDP) such as analyzing the business, requirement engineering, architectural design, implementation and test. Also, project management, configuration and change management are more complex than traditional SDP [REF-3].


Figure 1 – Trends and challenges in global and integrated system

3. Effort Estimation Methods

Many techniques have been introduced over the past years to estimate the required effort and cost for developing a software service. These methods have been initiated by simple equations and assumptions, and have now achieved complicated techniques [REF-7]. These techniques can be divided into the three general groups below:

  1. Expert judgment: In this method, which was proposed in the late 1960s and is still widely employed in various software companies, domain experts are asked to give their opinions on the required effort. Various amounts are expressed and, typically, their median is returned as the final required effort. The Delphi method is an example of this class of techniques.
  2. Algorithmic models: These models, which use mathematical relations and equations, seek to discover a relationship between service attributes and the required effort, are usually suitable for specific cases, and are adjusted and calibrated depending on the existing conditions. COCOMO, SLIM, SEER-SEM are examples of this type of methods [REF-6].
  3. Machine learning: These methods look to construct and study algorithms that can learn from datasets, are applied to inputs of the related problem, and help in the decision-making. Fuzzy theory, decision tree, ANN, and regression are examples of this class of methods.

Some of the benefits of machine learning methods include the ability to model complex relationships between dependent and independent variables and also power of learning from historical data. One of the disadvantages of the algorithmic methods is lack of flexibility and the need to calibrate themselves. These methods also do not have the ability to find the complex relationships between variables. Different kinds of regression, COCOMO models and COCOMO II are the most famous algorithmic models, and ABE, CART, Expert judgment and Artificial Neural Network, Learning and artificial intelligence techniques, fuzzy rules and optimization algorithms are the most popular non-algorithmic methods. Figure 2 shows the different types of effort estimation methods and their subsets.


Figure 2 – Various types of effort estimation methods

4. Effort Estimation Metrics

In the past, there was obviously a sense of the lack of a systematic approach to estimation GVS projects regarding the primary part of these projects–the services [REF-8]. This section is an aim to complete that space. The whole portfolio of a service development, big size service migrations and also technological innovation applications are supposed to obtain benefitted from the model since GVS is the standard in most of systems development projects across companies.

4.1 Functional Complexity

Complexity of a service operation may be mentioned through particular vital quantifiable variables which are usually taken. Here's a short explanation of the variables regarded for complexity computation in any one of the types [REF-9].

Demand message length: Quantity of different data sets being provided as input throughout service invocation.

Service volume: Sum of services and processes needed.

Weighted service interface number: The weighted quantity of revealed interfaces or operations per service as described in the WSDL docs.

Reply message length: Amount of distinctive data units being came back as output (in case two-way MEPs) during service invocation.

Information translation complexity: The difficulty of semantics and semantic translation which has to be utilized before demand is prepared or result is displayed.

Entities used: The primary enterprise objects/entities which are done something about as a result of the service operation.

Fault managing complexity: Specific error reporting requirements to be employed within the enterprise logic when invoking data or processing data/service.

Service invocation complexity: In situations where the service operation sets off additional services, this offers the no.

Information access complexity: In situations where the service operation would do something about the main information store explicitly (technologies besides the services), this shows the type of this kind of information access.

4.2 QoS Objectives

As explained previously, complexity of the service operation can be an element of the non-functional requirements which are designated for the service. These types of specifications are known as QOS purposes within this model [REF-10]. Here's a short explanation of the variables regarded for complexity computation in every one of the categories [REF-11].

Service composition style: The portion of services that are composite.

Stateless services: The portion of services that are stateless (SLS) versus state-full as described in the web services resource framework.

Concurrency: Will the service functionality require to assistance invocation by several customers simultaneously?

Testability: Testability demands of the service operating. Based on the complexity and quantity of dependencies of the procedure, this might or maybe not feasible.

Scalability: Require to support workload growing or in additional conditions capability to manage the better workload (messages/transactions per item of time).

Accessibility: Standards about service uptime and downtime/recovery in the event of failing.

Amount of service utilize: How many times is for each service applied by the enterprise. The concept will be to assess whether development sources have been utilized to produce services which are really applied by the company.

Security: Will the service require supporting specific security ways in the aspects of access handle, permissions or invocation monitoring?

Information weight: Scale of the information quantity to be managed by the procedure throughout an invocation.

Tracking: Unique demands if every relating to runtime checking & management of the service procedure on the hosting system.

Reusability: Standards concerning the reuse of the service procedure in other service combinations.

4.3 Integration Participants/Actors

A fundamental component of any estimation method is the actors associated with the program range becoming estimated. For GVS, it includes no direct "end users" which might be counted for in such a group. Rather the program actors are the ones which engage in service oriented integration as service, resource or data suppliers for the procedures being estimated.

Database interface: The service operation's business logic accesses a database directly through technologies such as JDBC, ADO.NET, etc.

Registered APIs: The service operating requires working with a COTS item or personalized applications giving a unique API or technology adaptors hence needing specific design to incorporate.

Service interface: Service operation's includes business logic that triggers other services via their published/well-defined interfaces or APIs.

Quantity of person activities: The portion of jobs included in a business flow which are manual.

4.4 Project Execution Environment

One last part of the puzzle in complexity recognition is the project context particular elements which have an effect about how much effort is required to be used throughout the lifecycle of the project. As the elements explained so far effect the service procedure, the environmental factors influence of the whole project rather than service operation. We now have observed following features impacting nearly all GVS projects (some are appropriate usually to all services).

Execution paradigm awareness: Based on the execution paradigm selected for the service delivery, this means the importance and presence of the paradigm information within the development group.

Group qualities: As service oriented architecture based development projects are naturally integration weighty tasks, is essential to think about the group qualities and also cooperation even as estimating. This parameter implies that feature.

Company information: Fine service oriented development needs the groups to possess sound ability to use business being covered by the services. This parameter represents the degree of enterprise area information existent within the group to be used on the project

Amount of services: Quantity of services that includes a GVS solution.

Engineering information: On the same traces, this parameter shows the degree of appropriate technical domain information contained within the group.

Conditions stableness: It is often identified and also confirmed time and again that stableness of demands run project plans and attempts on ground, whether or not it's traditional waterfall approach or agile. This parameter is employed to show the criticality and estimation of the stableness needed to be experienced in the project.

Service governance manages: The degree of service lifecycle governance handles also affect the effort that the groups must devote in spec creations, review and design of the service interface, monitoring and implementation. This parameter indicates this really quality control part of the SOA projects.

Service delivery equipment: During ground, the efficiency of the group is instantly proportional to the equipment that the group uses in the development, deployment and deployment of the services. This kind of automation assistance factor is mentioned with this parameter.

Please put in mind that the variables in all these classes are in no way complete nor perform these represent all feasible components required. Although, in the knowledge of the author they are mostly dealt with aspects which are examined throughout estimation in the organization GVS projects.

5. Conclusion and Future Work

It is time to expand the explanation of the phrase 'Software Engineering' according to the expression 'E-Services'. Hence, the description of the word E-Services has to be modified as Global Village Services with the priority of upcoming systems like cloud computing. The future generation governance frameworks are electronic governance data products to handle their incorporated services, that can be recognized through GVS. Global Village Service contains a global village service objective, a global village service requirement, a global village service result a global village, and service resource software solution. Service development effort estimation has an important role in service management. Precise estimation, because of the variety, abnormality, and complexity of services, is a hard problem. The main contribution of this article is the suggested group of metrics that can be tracked and calculated for each GVS engagement to ensure much better perception could be gleaned into the agility, complexity and effort value of the GVS application. Other work is also needed to supply obvious strategies to computing the values of the suggested combination GVS indices and analyze their issues.


[REF-1] Mcluhan, M., Understanding Media: The Extensions of Man, New York: Mentor. McNair, B.(1998) The Sociology of Journalism, London: Arnold, 1964.

[REF-2] Hashemi, S.M., M. Razzazi, and M. Teshnehlab, Streamlining the Global Village Grid Services. World Applied Sciences Journal, 2008. 3(5): pp. 824-832.

[REF-3] Hashemi, S.M. and M. Razzazi, Global Village Services as the Future of Electronic Services. 2011: Lambert Academic Publishing.

[REF-4] IEEE, Ieee standard glossary of software engineering terminology. Office, 1990. (1): pp. 1-21.

[REF-5] Hashemi, S.M., M. Razzazi, and M. Teshnehlab. Streamlining the global village grid through unifying e-governments, e-businesses, and e-commerce services. in 3rd International Conference on Information and Communication Technologies: From Theory to Applications, ICTTA 2008. IEEE. 2008.

[REF-6] Bardsiri, V.K., et al., LMES: A localized multi-estimator model to estimate software development effort. Engineering Applications of Artificial Intelligence Journal, 2013. 26(10): pp. 2624-2640.

[REF-7] Bardsiri, A.K. and S.M. Hashemi, Software Effort Estimation: A Survey of Well-known Approaches. International Journal of Computer Science Engineering (IJCSE), 2014. 3(1): pp. 46-50.

[REF-8] Bardsiri, A.K. and S.M. Hashemi, Electronic Services, the Only Way to Realize the Global Village. International Journal of Mechatronics, Electrical and Computer Technology, 2013. 3(6): pp. 1039-1041.

[REF-9] Gupta, D., Service Point Estimation Model for SOA Based Projects. Service Technology Magazine, 2013.

[REF-10] Bardsiri, A.K. and S.M. Hashemi, QoS Metrics for Cloud Computing Services Evaluation. I.J. Intelligent Systems and Applications, 2014. 12: pp. 27-33.

[REF-11] Hirzalla, M., J. Cleland-Huang, and A. Arsanjani. A metrics suite for evaluating flexibility and complexity in service oriented architectures. in Service-Oriented Computing–ICSOC 2008 Workshops. 2009. Springer.