Figure 1: Life Cycle
Abstract
Resumen
El desarrollo de software no solo necesita considerar el proceso de construccin, sino tambin otros aspectos tales como los costos, los recursos humanos y la comunicacin entre los interesados. La falta de simplicidad en este contexto se vuelve explicito cuando algunas restricciones tales como la arquitectura orientada a servicios, debe ser considerada como el estilo bsico para construir aplicaciones sustentables en entornos donde los profesionales no estn al tanto de esta tecnologa. Adems, la mayora de los procesos de software no son directamente aplicables o no son reutilizables, por lo que el tiempo de aprendizaje se vuelve un riesgo para el desarrollo del proyecto. Por lo tanto, Tape Mbo’e (TME) ha sido propuesto para apoyar la construccin de tales aplicaciones, en contextos como el de pases en vas de desarrollo donde se puede tener limitaciones econmicas y escasez de profesionales competentes. La primera aplicacin de TME has sido para desarrollar una aplicacin basada en servicios cuyo objetivo es la interoperabilidad entre sistemas legados de diferentes instituciones pblicas en Paraguay. Los resultados iniciales de esta experiencia indicaron la viabilidad y simplicidad de TME cuando se aplica en este campo. El proceso de evaluacin, sus resultados y conclusiones son descriptos en este artculo.
Keywords: Sustainability, Interoperability, Evaluation, Service-Based Application
Palabras claves: Sustentabilidad, Interoperabilidad, Evaluacin, Aplicaciones Basadas en Servicios
Received: 2014-07-29 Revised: 2015-02-26 Accepted: 2015-02-26
The interest in Service Oriented Computing has increased due to its observed benefits: support the interoperability among heterogeneous legacy systems, re-usability of functionalities and construction of adaptable and loosely coupled applications.
Building service-based applications requires repeatable software development processes to produce high quality software. On one hand, the existing development processes, like those proposed for object-oriented or component-based paradigms, do not completely satisfy the needs of service oriented application development [1]. On the other hand, the service oriented processes focus on developing services, but not on project management. Project management is critical in the construction of complex systems (e.g. e-government applications) to properly address different aspects such as human resources management, quality assurance management, and outsourcing, among others [2], [3]. ]]>
For these reasons, Grau et al. have proposed Tape Mbo’e (TME) (Tape Mbo’e means: “method” in Guarani Language), a service oriented process [4], [5]. It encompasses the whole life cycle of service-based applications (SBAs) that are built considering the sustainability, which means the capability of affording the operation of software in the long term [6]. Besides, an extended version of TME with life cycle, roles, disciplines, and work products is presented in this paper.TME was not built from scratch; it is based on Open Unified Process (OpenUP) (http://epf.eclipse.org/wikis/openup/), that has been chosen for being a light version of Rational Unified Process (RUP). RUP is a well-organized methodology and it has been widely used in the industry. However, it includes many artefacts and documents, making its use hard in this context because its adaptation would be time consuming and expensive [7].
TME has adapted OpenUP to support the development of SBAs. TME extends the life cycle and disciplines of OpenUP to cover the maintenance and retirement of applications and to assure the quality of SBAs. Besides, TME improves the project management discipline of OpenUP to consider the needs of development projects of public agencies of the Paraguayan government. The changes in this discipline have been inspired on the standard of project management [8].
We are aware that the changes proposed by TME reduce its agility. However, they support the sustainability, which is more valuable for the type of projects that we are interested in, such as the government projects.
TME is being applied for the first time in the Information Exchange System (IES) that is in charge of interchanging citizens’ data among the legacy systems of the whole public sector of Paraguayan government. The validation of TME represents a long-term study. However, the first observations indicated the feasibility and applicability of TME when used by practitioners. It is worth noting, that TME’s evaluation has been the first application of rigorous experimental evaluation in the public sector in Paraguay. Therefore, the first results of this experience are going to be described in this paper.
The paper is organized as follows. Section 2 depicts the TME including life cycle, roles, how the disciplines are performed during the life cycle, and differences between TME and OpenUP. Section 3 outlines the followed process to evaluate the application of TME in case studies. Moreover, the process is illustrated with the experience of applying TME in a public agency in Paraguay. Finally, conclusion indicates some future directions.
TME is a process for developing and maintaining service-based applications (SBAs), and it is based on Open Unified Process (OpenUP) (version: June 1, 2012). OpenUP has been chosen after examining various Agile Methods (AMs) such as Scrum [9], [10], Extreme Programming (XP) [11], [12], Feature Driven Development (FDD) [13], Dynamic Systems Development Method (DSDM) [13]. We have chosen OpenUP because it is the only one among those AMs that considers the project management and the deployment as disciplines. Its work products cover more aspects of the life cycle than the other AMs. Additionally, it is the light version of the Rational Unified Process (RUP). There are differences between TME an OpenUP, however; we will describe them in the next sections.
TME adopts the four phases of OpenUP and extends the life cycle of software development by adding the new “Operation Phase”.
The life cycle is iterative, incremental, and the phases are executed sequentially. Each iteration produces an incremental value to stakeholders, results of iterations should be defined in the iteration plan. The duration of the iteration might vary depending on project characteristics, but it is suggested to last for one-month.
The increment is a unit of work that can be used to measure project progress, and to make decisions in each iteration. ]]>
TME suggests that independent parts of the development can be carried out in parallel iterations.The next sub-sections describe the phases whose sequences of execution are illustrated in Figure 1.
Having determined the requirements, major decisions such as recruiting human resources, acquiring infrastructure, outsource the whole development or a part of it are taken. Also, the quality is planned.
At the beginning, the iteration is organized; this includes the selection of the requirement to be developed. Secondly, the selected requirement is described considering the remark of users, and it is refined incrementally.
Moreover, staff, schedule, and risks are all managed, and the quality of the work products are monitored and controlled. The output of this phase is a set of work products that describe the requirements (see Table 1).
Once the solution fits the requirements, it is ready to be tested by users in the next phase.
At the end, the software is deployed and the users are trained on how to operate it.
The corrective maintenance focuses on repairing faults and errors detected during the software operation while the perfective aims at improving code. The adaptive maintenance adjusts the application to support changes such as in the infrastructure layer; in the application context and location; of the user types, preferences, and constraints; in the functionalities provided by the composed services; in the way the service is being used and managed by its consumers. Furthermore, in this phase it is possible to adapt or substitute the component services to improve the performance of the software.
The evolution implies starting a new development cycle.
Finally, software retirement entails uninstalling the whole application or services from production environment. Due to its critic importance for service consumers, we have to assure the remaining services continue to work correctly.
Tape Mbo’e (TME) defines roles, each in charge of tasks needed to meet objectives. Its roles are like the three types proposed by OpenUP (http://epf.eclipse.org/wikis/openup/): Basic, Deployment, and Environment.
This type of roles encompasses those who participate in the development and the stakeholders.
TME introduces two changes in the basic roles of OpenUP, it removes the Any Role and add one of Quality Analyst. The former has been exempted because it does not participate in a specific discipline, while the latter is included to be in charge of the Quality Assurance discipline.
The roles are the following:
These roles are in charge of the tasks that are carried out after submitting the application. TME does not include the roles of “Course Developer”, “Product Owner”, “Technical Writer” of OpenUP.
TME assigns the responsibilities of the “Course Developer” to the “Trainer”, and it hands the responsibilities of the “Technical Writer” to the “Quality Analyst”. Also, it calls “User” to the “Product Owner”. The roles are the following:
These roles include people in charge of tools, configuration, and assets. TME considers the role of “Configuration Analyst” to be in charge of the Configuration and Change Management. Moreover, it excludes the role of “Process Engineer” proposed by OpenUP because its responsibilities are carried out by the Quality Analyst.
The roles are described as follows:
Tape Mbo’e (TME) follows an iterative, incremental, architecture-centric, and risk driven process. It is represented by analysing two dimensions: temporal evolution (life cycle) and disciplines as it is illustrated in Figure 2. The former shows the software life cycle, while the latter mentions the disciplines involved to produce software [4].
A discipline is a set of tasks that have a common goal, and produce work products. The work products can be documents (manual, planes, schedule, contract, etc.), models, code, templates, mock-ups, service level agreement (SLA). The disciplines are executed during the life cycle, and each of them is under the responsibility of one of the aforementioned roles.
TME proposes six disciplines whose relationships are shown in Figure 3. The vertical disciplines (i.e., Project Management and Quality Assurance) are in charge of organizing, controlling, and suggesting tasks to the horizontal disciplines.
The disciplines, their sub-disciplines, work products, and the phases in which they are carried out are presented in Table 1 and described bellow.
The major goals are the definition and delimitation of the development project. These are accomplished through the following disciplines:
Project Management. The project is established applying the next sub-disciplines:
The risks are identified, and suitable responses to them are planned.
Moreover, the work breakdown structure (WBS), schedule, and budget are elaborated as part of the project plan.
The team is organized, and its members are notified about their responsibilities and functions.
In addition, training courses for the staff of the project are planned.
Furthermore, the meeting frequency is established. Meetings with users are arranged and performed, and during those meetings, the major decision of the project are taken.
Meeting minutes are elaborated to report on the topics discussed in these meetings
The suppliers are called, and their proposals are assessed in order to carry out the selection process. Finally, negotiating, awarding, and the signing of the contract with the selected supplier is done.
Quality Assurance. It aims at planning how the quality during the whole project will be managed. The following sub-disciplines are considered.
Requirements. The major project requirements are identified with users, and these are ordered by priority.
This phase is characterized by the activities of analysis and design. Therefore, it involves the following disciplines:
Project Management. It is performed through the next sub-disciplines.
The tasks of monitoring, controlling, and updating scope, risks, schedule, and cost are carried out.
Moreover, team meetings are held according to the settled frequency, as to update about progress, pitfalls, and support decision-making.
Quality Assurance. It focuses on the quality of design and keeping assets version. These following sub-disciplines are involved.
The quality of the design is monitored, and corrective actions can be suggested.
A glossary is created to unify concepts that can be either incompatible or different across diverse legacy systems.
Finally, use cases, mock-ups, and glossary can be refined, and the requirements list can be updated.
Architecture. It focuses on defining, depicting, and updating the application architecture. It is performed through the following sub-disciplines.
The process description is made using Business Process Modelling Notation (BPMN) that has been chosen for being a standard notation (http://www.omg.org/spec/BPMN/2.0/). BPMN involves process, sub-processes, activities, services, flows, and entities.
TME calls Business Model to each BPMN diagram, and suggests describing with BPMN each use case identified by the Requirements Discipline.
The meta-model represents the applications as components, and the services as interfaces. Relation of dependency connects the service consumed with its component, and relation of realization links up the service provider with its component. ]]>
As an example, the Domain Model of Information and Interchange System (IIS) shown in Figure 5 is proposed. The model includes the systems of the following agencies: Civil Registration Office (CROS), Ministry of Education MES), Ministry of Heath (MHS), Secretary of Information and Communication (IIS), National Police (NPS), and Ministry of Treasury (MTS). CROS provides the birthService and deathService while NPS supplies citizenPoliceRecordService. IIS consumes these services, and composes them into the citizenDataService consumed in turn by MES, MHS, and MTS. We can observe how the domain encompasses legacy systems and also produced and consumed services for them. This supports the re-usability of functionalities and services.The application is decomposed into modules, which are held in the Structure Model.
Furthermore, this sub-discipline defines the interchange standards including data format and processes. An example of standard data format is presented in Figure 6. The example is in XML Schema Definition (XSD), a format in which the service providers present the information needed to consume their services.
The identification of services to be re-used is another important activity. It is expected to reduce redundancy, development time, and save costs for both maintenance and operation. TME suggests the application of techniques for service identification, but does not indicate a specific one. However, some suggestions can be found in the work of Arsanjani et al [14] which are Domain decomposition, Goal-service modelling, and Existing Asset Analysis [15], [16], [17], [18]. The techniques focus on searching a set of candidate services which might accomplish the development requirements. The search can embrace business processes, existing assets which include legacy systems, functionalities, procedures, existing services into service repository, rules and others [15]. After discovering the candidate services, they should be filtered according to pre settled criteria such as Service Litmus Test (SLT) [14], [16]. SLT is a set of tests applied in iterative way to assess service candidates in order to select those which will be re-used. Finally, the selected services are developed, unless they have been already deployed in the service repository. ]]>
The domain model, the structure model, the interchange standards, and the glossary of terms can be refined and updated.The service structure is described with inputs, outputs, messages, ports, and protocols according to the UML meta-model proposed by De Castro et al [19]. The meta-model is shown in Figure 7, and it represents the WSDL with a UML class diagram in which each part of WSDL is a class. The model is called Service Model.
The database is designed and depicted using UML class diagram and/or entity-relation diagram, this representation is called Data Model.
Additionally, the service model and the data model can be refined and updated.
The effort is focused on building an application that fulfils the requirements and quality standard. Therefore, the disciplines are applied as follows: ]]>
Project Management. It is performed through the following sub-disciplines.Quality Assurance. It is accomplished through the following sub-disciplines:
The changes of project assets are monitored, and the version is updated if needed.
Furthermore, the tools to be used for programming are installed and customized.
Requirements. The requirements list, use cases, mock-ups, and glossary can be updated.
Architecture. It is performed through the following sub-disciplines:
Besides, the domain model, the structure model, the interchange standards, and the deployment model can be refined and updated.
Deployment. The plans of deployment and back-up are elaborated.
Once the application is finished, it is deployed in test environment.
Once the software is ready to be delivered, its verification, validation, and acceptance are carried out by users. Finally, it is deployed and its productive life starts.
In this phase the following disciplines are involved:
Project Management. It is performed through the following sub-disciplines.
The analysts meet with users to verify and validate the application. Furthermore, users are trained to use the software.
Quality Assurance. It is performed through the following sub-disciplines.
Furthermore, the deliverable documentation and manual are elaborated to be given to final users.
Requirements. The requirements list is updated.
Deployment. The infrastructure where the application will be installed is verified to ensure its adequacy, and corrective actions can be suggested. Then, the software is installed in production environment, and the services are published in the service repository. The services repository provides information about business entities, the type of services, and mechanisms for accessing to them. The industrial standards of service registry are the Universal Description, Discovery and Integration (UDDI) and Electronic Business Markup Language (ebXML) thought the most widely spread is UDDI [20].
In addition, the deployment can be reversed if necessary.
The activities focus on ensuring the effective and efficient performance of the software. Moreover, the software or part of it can be retired of the production environment; in this case, the operation of related applications has to be assured.
These activities are achieved with the following disciplines:
Project Management. It is performed through the following sub-disciplines.
Quality Assurance. It is performed through the following sub-disciplines.
Requirements. The glossary can be updated.
Architecture. The business model, the domain model, the interchange standards, the structure model, and the deployment model can be updated.
Development. The corrective, adaptive, and perfective maintenance are performed.
As we stated in Section 2, it is possible to adapt and substitute the constituent services to improve software performance. TME considers mechanisms to monitor the needs for adaptation. Once adaptation requirements are detected, it is possible to choose the most suitable mechanisms to carry out the adaptation. The mechanism to be implemented depends on the change that promotes these needs. Some of such mechanisms could eventually support self-adapting service based applications.
Before retiring software from the production environment, all the related legacy systems have to be examined and adjusted if necessary. Thereafter, the retirement takes place and the environment is tested again.
Deployment. Updates are deployed into production environment, and / or into the service repository. The software can be returned to a previous state if necessary.
TME has introduced various changes into OpenUP, mainly, in the life cycle, roles, and disciplines. The goal of these changes has been to provide to OpenUP with the characteristics required to support the development of SBAs. Besides, they intend to overcome some weaknesses of OpenUP such as the lack of quality assurance; a life cycle disregards maintenance and retirement; project management that does not consider outsourcing, human resource, and so on.
Considering this, TME has incorporated a new phase into its life cycle “Operation Phase”, in order to cover the gap between deployment and retirement of the application in OpenUP’s life cycle.
On one hand, TME has added the new discipline “Quality Assurance”, to assure the quality of the process and work products; and has included the Test Discipline of OpenUP into this new discipline, as a sub-discipline. On the other hand, it has given up the Environment Discipline of OpenUP, because its functions are covered by the Configuration and Change Management sub-discipline. ]]>
In addition, TME has modified various disciplines of OpenUP; the major changes have been into the Architecture and Project Management disciplines. They have been separated into sub-disciplines to specialize their management, and their work products have been incremented as well (see Table 3).TME has introduced the new work product “mock-up” to the Requirements discipline. Since the service oriented computing involves a new programming paradigm, the Development discipline has been adjusted, including the service composition and the Deployment discipline to consider service publication into the service repository.
All these changes have affected the definition of roles, consequently. Two roles: Quality Analyst and Configuration Analyst have been added. Moreover, TME has excluded roles whose functions are covered by others, namely the: “Any”, “Course Developer”, “Product Owner”, “Technical Writer”, and “Process Engineer” roles.
The major changes incorporate in TME are shown in bold face in Tables 2 and 3.
To summarize, we highlight the improvements that TME has proposed, as follows:
Moreover, TME covers a larger domain by including operations outside the scope of OpenUP
OpenUP involves the test practices, but does not envisage the user acceptance.
For all of these reasons, TME seems to be an interesting process in order to produce and maintain high quality service-based applications whose life cycle is supported by a well-defined project management.
The assessment is inspired in the evaluation framework proposed by Grau et al [3] whose baseline is the work of Cernuzzi and Rossi [21]. The evaluation plan is composed of three phases: Planning, Execution and Analysis.
The goal of this evaluation step is to identify the relevant questions that will be answered.
To do so, we focus on answering the following questions:
With the research questions defined, for each of these questions we proceed to define a set of goals using GQM technique [22]. GQM separates goals in sub-goals hierarchically, as a tree where the leaves are the metric-associated questions used to measure the goals’ achievement. The major goals with their sub-goals are described as follows (see Table 4).
SO Service Oriented. Is related to intrinsic characteristics of service computing and data interchange issues. Its major sub-goals are the following:
SE Software Engineering. Involves the qualities that are required to be present for any software engineering process. Its major sub-goals are the following:
PM Project Management. Involves the fundamental activities necessary to manage any type of project according to project management standard [8]. Its major sub-goals are the following:
Two types of measurements are done: direct and indirect. The former is used for leaves while the latter for the others. For each of theses types the following measures have been established: Frequency and Aggregation. These measures are described in Table 5.
The scale of the Aggregation Measure encompasses the range of values that are interpreted as the degree of satisfaction for goal achievement. The interpretation of the Frequency and Aggregation Measures is shown in Table 6. ]]>
The leaves are the questions answered by practitioners. These are measured by giving it a value found in the Frequency Scale (see Table 6). Once all the questions are answered, the value of non-leaves (goals and sub-goals) is calculated by finding out the arithmetic mean () obtained with Formula 1. Thus, the value of a non-leaf is equal to the arithmetic mean calculated from its child nodes.
|
Different practitioners can be interviewed for a given case study. Each of these practitioners responds a questionnaire that contains a set of questions that are grouped according to the goals of the tree of goals, and they aim to measure its achievement (see Table 4). The possible responses to each question is in a frequency scale (see Table 6), as the example shown in Figure 8 shows.
The questions chosen are matched with their numerical value in a measurement template. Figure 9 shows the measurement template for the example of Figure 8 that corresponds to the questionnaire 
.
Using this the value of sub-goals, goals, dimensions, and total value are calculated. Finally, the total value of the case study is the upshot of combining the dimensions and the total value of all the questionnaires. The combination is done through obtaining the geometric mean (G) with Formula 2.
|
The results of Formulas 1 and 2 are given using the Aggregation Scale (see Table 6). ]]>
This linear model is very simple and will probably be replaced by a more powerful aggregation mechanism, like the Logic Scoring of Preference [23]. Moreover, according to the objective of the stakeholder it is possible to associate a priority or different weights to specific goal and /or any goal of the tree to better cover significant aspects for the assessment. Such differentiation accommodates the needs of assigning priorities to a specific aspects and a more sophisticated comparative analysis. However, we leave this consideration for future works.The goal of this phase is the execution of the evaluation plan by running case studies. From the set of evaluation studies already performed for our case study, we will described the first one in the following section.
TME was first evaluated in a case study regarding an Information Exchange System (IES) developed in a public institution in Paraguay (PIP). The PIP was set up in April 2012 and, before using TME its development process used to be informal, according to the information collected from its quality analyst in October 2012.
The PIP used TME to manage the development of the IES, which had as its main goal the interoperability of legacy systems in public agency through the use of service-oriented computing. The operation of the mentioned IES is as follows: first, it consumes services from the providers; second, it integrates these services into a new single service; and thirdly, it provides this new service (see Figure 6). It will take some years to complete the full development of the IES. Therefore, this first evaluation encompasses the period from October 2012 to March 2013.
During this period, four services were developed that exchanged citizens’ data from five legacy systems that belonged to different public agencies. Each agency has a development team that is represented by a leader. The leader of the PIP is in charge of managing the communication among all leaders, and the PIP is responsible for defining the interoperability standards such as data format (see Figure 6), request process and to access to a service etc. The development team is in charge of services development for the owner of the legacy systems (provider or consumer). At the moment, there are three consumers, but this number is planned to increase in the future.
There have been six teams in charge of developing the IES. However, our analysis only involves the PIP team that was composed of a project manager, a leader, an architect, a quality analyst, and three developers. The project manager and one of the developers have a degree in computer sciences; the leader, the architect, the quality analyst, and one of the developers are system engineers; one developer is a student; and finally, the quality analyst is a Ph.D. student.
As far as professional experience is concerned, the project manager, the leader, the architect, the quality analyst, and one of the developer have been working in diverse projects, for more than ten years. One developer worked in a project before the IES, while for the other developer this is its first work.
The first part of the IES development was financed by a sponsor who monitored the development and demanded that his own quality standards to be followed. The sponsor support lasted until March of 2013.
The IES construction was delayed several times before due to some external factors such as political reasons, lack of a law that regulates exchange of sensitive data, and staff changes. The regulating of exchange of sensitive data was only passed on January 2013, which facilitated the decision making regarding the system.
Definition of the Assessment Scope. The evaluation encompassed from the Inception Phase to the Transition Phase, over the course of six months. Focusing above all in the interoperability of legacy systems that can belong to different public agencies, the project management, and the sustainability of the project. ]]>
Since we were able to implement TME only in the PIP, the assessment considers only this agency.The interviewees where selected according to their knowledge on the whole process proposed by TME. Furthermore, it was required that they were part of the IES team of during the period from October 2012 to March 2013. Only the team leader and the quality analyst fulfilled these requirements.
Data Collection. The questions associated to each goal or sub-goal were presented in a questionnaire that was answered by the case study participants.
The questionnaires were then sorted out in Control or Experimental categories, according to the process that they report on. The control questionnaires were answered by the control group, these inform about the process of development before applying TME in the PIP. The experimental questionnaires were answered by the experimental group (i.e the team leader and quality analyst) and they measure TME’s performance.
The questionnaire used for this case study is composed of 83 questions that measure 20 sub-goals. The questionnaire is written in the local language (Spanish), and it takes 20 minutes approximately to be filled by the practitioners. An example of the format of the questionnaires is shown in Figure 8. We assign a numeric value in the Frequency scale to each response of the questionnaire. Having completed the questionnaire, the numeric value of each selected response is registered in a template to calculate the results (see Figure 9). The control questionnaire (CC) was answered by the quality analyst before applying TME. After six months of TME implementation, its performance was examined from the viewpoint of team leader (
) and the quality analyst (
) who filled in the experimental questionnaires.
It is worth noting that for the purpose of this study all the goals and sub-goals have the same weight. However, according to the stakeholder’s objectives of the TME allows to assign different weight to specific goal and/or any goal of the tree.
Measuring Process. Once the questionnaires were completed, their responses were matched to the values of the Frequency Measure (see Table 6). Subsequently, the values of goals and sub-goals were obtained according to the process defined in Section 3.1.4.
As the questionnaires are clustered by type, next step was to follow the process defined in Section 3.1.4.
According to the range of values in which the numerical results are to be interpreted, these were matched to the scale of Aggregation Measure. The tree of goals with the results of the three questionnaires (i.e, 1 before TME and 2 after adopting TME) is shown in Table 7. Note that the results are in aggregation measure, and the questions (which are measured in frequency measure) are not presented.
The results for each dimension in Aggregation Measure are shown in Table 8, and the final result is “Normally”. ]]>
Since the questionnaires are the tool used to measure the achievement of the goals, their reliability affect the validity of the evaluation. For this reason, they have been elaborated to embrace all the aspects related with the goals and their questions strive to be accurate and easy to understand. It is also important to note that the validity is constrained by the skills and perception of the interviewees.
Another limitation is that only two persons were interviewed. Even though these two persons are considered proficient professional, and they have been in charge of important projects in public and private sector in Paraguay.
Even though one study is not enough to support a strong claim, independent observers have managed to observe improvements in their processes due the use of TME.
It is worth mentioning that almost all the dimensions achieved the value “Normally”, and particularly the Sustainability goal achieved values very close to “Always” (see Table 8):
Service Oriented Dimension. The score given to this dimension is “Rarely”, this means that less than the 50% of the time, the suggestions of TME have not been observed (see Table 8). Nevertheless, if we consider its the numerical value of “2,44” we can appreciate that it is quite close to “2,5” that represents “Normally”.
Even though TME suggests signing the Service Level Agreement (SLA), having a service repository (UDDI), and implementing techniques for concepts unification; they have not been implemented by the PIP (see Table 1). Table 7 shows that the “Service Implementation” is the weakest goal of this dimension. Moreover, the quality analyst did not give an answer on the “Service Implementation”, because she did not participate in the development.
Previous processes of the PIP have obtained a “Never” mark, so when comparing this with the “Rarely” mark obtained through TME, we can observe that TME has improved the development process of the PIP in response to the question research “Q.1”.
Software Engineering Dimension. There are different responses in Requirement and Configuration, and Change Management due to practices and documents proposed to them; but they have not always been considered by the developers.
The quality analyst suggested to follow certain standards during the development, but it was not her responsibility to guarantee that the developers really followed the suggested standards. ]]>
Testing has not always been carried out by other people besides developers and there was not a responsible person for accepting the development before deploying. Besides, verification and validation practices were not suggested at that moment.This dimension has obtained the mark “Normally”, which means that more than the 50% of the time the suggestions of TME in the “Software Engineering” area have been observed. This result suggests that TME has improved the previous process of the PIP, considering the question research “Q.2” (see Table 8).
Project Management Dimension. Various processes and documents were not followed and completed because they were unknown by the majority of the staff due to a fault in Communication Management. This situation is reflected in the very low score in “Communication Management”, and affected the Role Assignation because some members of the team were not notified about their responsibilities.
Part of the IES development was outsourced, and the contract with the provider was signed before applying TME. For this reason, several of TME’s suggestions were not been considered.
Sustainability Dimension. Even though the models were not easily understandable to some of the staff, the documentation was usually updated.
The PIP determined that all the tools used for developing IES should be open source. These tools include database, programming language, modelling language, project management software, version control software, etc. Moreover, TME includes standard notation such as UML and BPMN.
However, the lack of documentation of the applications developed at the PIP before applying TME has hindered their maintenance.
Since the previous process of the PIP obtained the “Never” mark, when comparing it to the “Normally” mark obtained with TME we can consider that it has become more sustainable than the previous process in response to research question “Q.4” (see Table 8).
Among the various Agile Methods, OpenUP has been chosen to be the baseline of Tape Mbo’e (TME). Furthermore, TME is a service oriented process that modified the life cycle and the disciplines of OpenUP. The former covers the maintenance and retirement of systems while the latter includes the service oriented computing features, the quality assurance, and improvements to the project management. These changes have affected the definition of roles and work products as well. Consequently, TME introduces new roles, gives up some existent roles, and includes new work products.
On the one hand, TME aims at proposing a general process. For this reason, the processes for addressing more specific aspects such as the publication of services on the service repositories have not been included by this version of TME. It is worth noting that TME is not a methodology, consequently, specific aspects like techniques for service identification, criteria for reusing functionalities, metrics to measure the complexity of the development, etc. are not presented here. However, as mentioned in section 2.3 for service identification, TME consider the adoption of other existing proposal. ]]>
To evaluate the TME, we prepared an evaluation plan that is described in Section 3. This plan includes goals, measures, and scales. In addition, it applies Goal-Question Metric to organize the overall observation structure and guide the case studies execution.This paper has presented the results of the first case study evaluated with the TME plan, which is also the first application of rigorous experimental evaluation in the public sector in Paraguay. The case study is the Information Exchange System (IES) which belongs to a public Paraguayan agency. The development of IES had been addressed using TME and its performance was assessed. In the evaluation TME has demonstrated to contribute to the agency’s improvement when compared to the previous process as it is shown in Section 3.4.
The assessment of other case studies is still on going. These represent the experiences of using TME in different public and private organizations in Paraguay. The results of those case studies are currently being integrated by using meta-analysis (non-parametric aggregation) through Vote Counting [24]. Since this paper intended to discuss just one of these case studies, the use of vote counting is not feasible.
As future work we are going to present the results of assessing TME with vote counting. In addition, in order to outfit TME with a set of suggestions about existing techniques, we have researched about techniques for service identification and criteria for their selection, techniques to estimate the project size, criteria to reuse existing assets, etc.
The contributions of this paper are the description of the evaluation plan and its application to the first assessment of TME’s performance in a real case study in Paraguay.
[1] V. Andrikopoulos, A. Bucchiarone, E. D. Nitto, R. Kazhamiakin, S. Lane, V. Mazza, and I. Richardson, “Service engineering,” in S-CUBE Book, 2010, pp. 271–337.
[2] S. Lane and I. Richardson, “Process models for service-based applications: A systematic literature review,” Inf. Softw. Technol., vol. 53, no. 5, pp. 424–439, May 2011. [Online]. Available: http://dx.doi.org/10.1016/j.infsof.2010.12.005
]]> [3] I. Grau, L. Cernuzzi, and A. Villafiorita, “Analysing service oriented methodologies for sustainable applications,” in The 32nd International Conference of the Chilean Computer Science Society (SCCC), November 2013.[4] I. M. Grau, L. Cernuzzi, and A. Villafiorita, “Tape Mbo’e TME: A service oriented process,” in The 32nd International Conference of the Chilean Computer Science Society (SCCC), November 2013.
[5] I. Grau, G. Travassos, L. Cernuzzi, and A. Villafiorita, “Tape Mbo’e: A first experimental assessment,” in Actas del XVII Congreso Iberoamericano en Software Engineering, CIbSE 2014, (Experimental Software Engineering Latin American Workshop - ESELAW), April 2014.
[6] B. Eshete, A. Mattioli, A. Villafiorita, and K. Weldemariam, “ICT for Good: Opportunities, Challenges and the Way Forward,” in Fourth International Conference on Digital Society, 2010. ICDS ’10., feb. 2010, pp. 14–19.
[7] I. Christou, S. Ponis, and E. Palaiologou, “Using the agile unified process in banking,” IEEE Software, vol. 27, pp. 72–79, may-june 2010.
[8] A Guide to the project management body of knowledge. Project Management Institute, Inc, 2008.
[9] K. Schwaber, Agile Project Management With Scrum. Redmond, WA, USA: Microsoft Press, 2004.
[10] P. Deemer and G. Benefield, “The scrum primer. An introduction to agile project management with Scrum,” 2007. [Online]. Available: http://www.rallydev.com/documents/scrumprimer.pdf
[11] S. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. New York, NY, USA: John Wiley & Sons, Inc., 2002.
[12] K. Beck and C. Andres, Extreme Programming Explained: Embrace Change. Addison-Wesley Professional, 2004.
]]> [13] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, “Agile software development methods - review and analysis,” VTT PUBLICATIONS, Tech. Rep. 478, 2002.[14] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Gariapathy, and K. Holley, “SOMA: a method for developing service-oriented solutions,” IBM Systems Journal, vol. 47, pp. 377–396, July 2008. [Online]. Available: http://dx.doi.org/10.1147/sj.473.0377
[15] Y. Tian, Y. Su, and X. Zhuang, “Research on service identification methods based on SOA,” in 2010 3rd International Conference on Advanced Computer Theory and Engineering (ICACTE), vol. 6, Aug. 2010, pp. V6–27 – V6–31.
[16] N. Zhou, L. Zhang, Y. Chee, and L. Chen, “Legacy asset analysis and integration in model-driven soa solution,” in 2010 IEEE International Conference on Services Computing (SCC), ser. SCC ’10, Washington, DC, USA, july 2010, pp. 554–561.
[17] L. Zhang, A. Arsanjani, A. Allam, D. Lu, and Y. Chee, “Variation oriented analysis for SOA solution design,” in IEEE SCC. IEEE Computer Society, 2007, pp. 560–568.
[18] K. Levi and A. Arsanjani, “A goal-driven approach to enterprise component identification and specification,” Commun. ACM, vol. 45, no. 10, pp. 45–52, Oct 2002. [Online]. Available: http://doi.acm.org/10.1145/570907.570930
[19] V. de Castro, E. Marcos, and B. Vela, “Representing WSDL with extended UML,” Revista Colombiana de Computación - RCC, 2004.
[20] W. T. Tsai, X. Zhou, Y. Chen, B. Xiao, R. Paul, and W. Chu, “Roadmap to a full service broker in service-oriented architecture,” in Proceedings of the IEEE International Conference on e-Business Engineering, ser. ICEBE ’07. Washington, DC, USA: IEEE Computer Society, 2007, pp. 657–660. [Online]. Available: http://dx.doi.org/10.1109/ICEBE.2007.95
[21] L. Cernuzzi and G. Rossi, “On the evaluation of agent oriented modeling methods,” in Proceedings of Agent Oriented Methodology Workshop, 2002, pp. 21–30.
[22] V. Basili and D. Weiss, “A methodology for collecting valid software engineering data,” Software Engineering, IEEE Transactions on, vol. SE-10, no. 6, pp. 728–738, 1984.
]]> [23] J. J. Dujmovi’c, “The LSP method for evaluation and selection of computer and communication equipment,” in Proceedings of MELECON’87, Mediterranean Electro technical Conference and 34th Conference on Electronics, IEEE/RIENA, 1987, pp. 251–254.[24] G. V. Glass, “Primary, secondary, and meta-analysis of research,” Educational Researcher, vol. 5, no. 10, pp. 3–8, 1976. [Online]. Available: http://dx.doi.org/10.2307/1174772
