Human-centered software development methodology in mobile computing environment: agent-supported agile approach

Abstract

Due to the large demand of the services from the wireless networked computing environment, the capacity and performance of wireless devices, platforms, and applications are improved. Especially, in recent years, the use of mobile applications has increased dramatically along with the concept of ‘smart’ phone. As a result, the center of human e-life has been transferred from a conventional desktop space to a mobile wireless computing environment. These rapid changes also generate additional requirements for more sophisticated and complex functionalities in wireless computing environment such as personalization or adaptation which result in the requirements of ‘human’-centered software development methodology in wireless computing environment. Although there are well-known classical software development methodologies such as waterfall, they do not fit to the characteristics of wireless computing environment. Instead, the agile software development methodology is generally used to deal with dynamically changing requirements in wireless computing environment. However, agile software development methodology is knowledge- and labor-intensive and does not fully cover the requirements that are essential to the wireless computing environment. In this paper, we analyze the requirements of mobile applications in wireless computing environment and propose a human-centered software development methodology which is to integrate agile philosophy and agent technology. Additionally, we employed the concepts of software product line engineering in order to understand and represent the variability of dynamically changing requirements. Consequently, what we propose in this paper is an agent-supported agile-based mobile software development methodology in wireless computing environment for supporting adaptive requirement changes and their automatic implementation. In order to demonstrate the feasibility of the proposed approach, we have performed two experimental case studies by developing android mobile applications.

1. Introduction

Recently, we are witnessing an explosion of mobile applications with a lot of multimedia services driven by the various mobile technologies in wireless computing environment. Furthermore, the user's expectation toward functionalities and qualities keeps increasing through the appearance of ‘smart’ applications in the wireless computing environment. Users cannot be satisfied with one-dimensional functionalities in such environment. They want the mobile applications to be more intelligent. This intelligence includes the ability of recognizing the user's intention and context and the ability of adapting to the dynamically changing environment by itself. In other words, the demands for the software adaptation requirements move to the next level, which requires more intelligence, in the mobile computing environment (MCE). In order to support such software adaptation, a large scale of data should be continuously monitored and supervised. A large amount of information must be collected and analyzed as an information lifecycle. This is shown in Figure 1. Moreover, the additional requirements of users, systems, and their interactions, which are not elicited during the requirement engineering process, should be discovered from the actual usage of the application by the users.

Figure 1

Movement on mobile computing environment.

From the above observations, we focus on three problems. Firstly, there is no existing applicable software development methodology that reflects the characteristics of MCE and its adaptation requirements. Secondly, additional requirements of software adaptation keep accumulated on top of existing requirements by adding the increased complexity of software and its engineering process. Lastly, a well-structured information processing lifecycle is needed to model, analyze and retrieve the complex and sophisticated information from the dynamically changing users, systems and the environment. Thus, our approach integrates agile philosophy and agent technology to resolve the above problems. The proposed framework (in Section 5.4), which adopts the human-centered software development methodology, is based on the hybrid use of the above two concepts.

2. Problem statement

2.1. Problems

As described in the previous section, there are some problems on the process of mobile software development. Those problems are as follows:

• Conventional software development methodology cannot be applied to the mobile software development.

• The complexity of mobile software engineering is increasing.

• Knowledge- and labor-intensive processes create additional burdens.

Firstly, the MCE is different from the conventional computing environment. The lifespan of mobile software is quite dependent on the usability, and this usability is also dependent on the user requirements. Requirements from mobile software users are variable and capricious. Thus, if we want to make a long-term mobile application on the MCE, it is critical to reflect and satisfy the dynamically changing requirements. Also, the accuracy of processed information for adaptation is important. The MCE has limited resources, including memory, battery, and display. Therefore, developers are required to consider these limited resources. These differences and restrictions make the conventional software development methodology inapplicable for the mobile software development. The additional requirement of adaptation also pulls variable cases and variants, which should concern the developer. In other words, the applications in the MCE need to be more intelligent. They need to recognize the dynamically changing environment and properly react to those changes. To develop such application, the conventional development methodology is not sufficient. Therefore, some labor- and knowledge-intensive processes and complexities exist in the background of realizing adaptation, and this is why the novel development methodology is proposed in this paper.

2.2. Objectives and propositions

In this research, our study aims to analyze the design of the software development methodology specialized in adaptive mobile-software development. The purpose is to find a way to control the complexity and to reduce burdens during the process of adaptation realization. In detail, we have several propositions which are as follows:

• Reflecting features of the MCE

• Reflecting the adaptation requirement

• Controlling complexity on adaptive mobile software engineering

• Reducing loads from labor- and knowledge-intensive process of developers

• Improving accuracy and functionalities

Basically, the features of MCE have to be reflected onto the methodology, not to miss the factors affecting the usability of the mobile application. Through this, developers can avoid the risk of an early buried and dead application. Then, we should reflect the adaptation of the found factors. These factors become the requirements of the development, and they need to be adapted into the mobile software development process by the adaptive functions. After reflecting additional requirements, the complexity, which is increased by the dynamically changing requirements for the adaptation, needs to be managed. Finally, for more usability of adaptation, sufficient accuracy of information and functionalities of application must be achieved.

3. Related works

3.1. Features of mobile computing environment

MCE includes the environment of the mobile software's execution and the environment of the mobile software's development. The MCE has more limitations compared to the conventional computing environment. Most of them are the constraints on resources, which are as follows:

• Memory. The amount of memory that the application can use is limited by constraints of resources.

• Battery. The amount of the power consumption is limited by the physical size of the mobile devices and the impossibility of power supply.

• Display. The size of display is limited, so that the arrangement of information and view needs to be considered.

• Signal. As many functions of the application are based on network environments, the stability of signals is required.

• Speed and smoothness. To keep the real-time usability present in the user's life, the speed and smoothness of mobile software have to be assured.

• Maintenance. To satisfy changing requirements and updating new information and functions, continuous upgrade and communication with users are needed.

Because of these constraints, mobile applications avoid constructing huge data structures and weighted computations, and pursue compactness and lightness. In addition, users on MCEs need to be active to express opinions on applications they frequently use, and these requirements are various and variable.

3.2. Agile software development methodology on MCE

The agile software development methodology was proposed to resolve the problems of conventional software development methodology, which shows stiffness and intensive labor on the preparation and document process [1]. Thus, the agile methodology focuses on the member's capability, synchronization, and sustained deployment of products. By these principles, the software development process based on agile methodology generally includes the iterative and evolutional development processes [2] such as Scrum and XP [3, 4]. Due to flexibility and short-term iteration of the agile process, the agile methodology is usually applied to mobile software projects [5]. Thus, the agile methodology has been discussed for mobile software development like the Mobile-D project [6]. However, there is no widely agreed software engineering process for the MCE which considers the dynamic requirement adaptation.

3.3. Agent and software product line

An agent is an encapsulated computer system that is situated. From the establishment of this definition, the study of agent-oriented software engineering (AOSE) or agent-based approaches for software engineering has been researched steadily [7]. AOSE is to adapt the agent concept to software engineering in order to control the complexity field, called as AOSE by Jennings and Wooldridge [8–10].

Software product line engineering (SPLE) is a field of software engineering involving the production of serial applications through distinguishing variable parts from unchangeable parts. The domain and variability concepts of SPLE are used to express the variable and common components in a software system. Presently, these concepts are used to describe the architecture of an adaptive software system as a changeable software at runtime. In SPLE, adaptive software is regarded as the system containing the different software at a different case in one product line. Through using SPLE concepts on engineering an adaptive software system, systems and developers can realize where and how the system changes.

4. Approaches

Now, we introduce our solution and approaches to the problems described above. Basically, our solutions are based on the hybrid of three concepts: agile, AOSE, and agent technology. That is, these approaches were developed through combining three ideas, which look isolated at first glance. Therefore, in this section, we explain how those key ideas are combined and used to build our solution.

4.1. Mobile computing environment and agile

As seen through the explosion of the popularity of mobile devices and applications, mobile software supports many services with or without the support of a desktop settled on human life. Hence, requirements for improved function and service approach need to be considered. To satisfy their requirements, developers have to speed up the progress of engineering and strive to produce good performances during relatively tight schedules. Moreover, mobile software and devices have inherent constraints, which produce additional requirements concerning processes.

Agile software development methodology is already used for the development of mobile software for the reason that the agile methodology is capable of covering some critical features of the MCE:

• Various requirements. In the MCE, mobile software requirements are changeable for various reasons like the user's needs, capabilities of devices, platforms, etc. Thus, for mobile software development processes and maintenance, frequent tests and revisions are needed to reflect various requirements of users and markets.

• Labor- and knowledge-intensive. For dynamically changing requirements and relatively strict terms for development, project members go through many turning points and iterative processes. Moreover, the quality of their results and development processes rely on the capabilities of the project members. Therefore, modern mobile software requires much knowledge and labor.

• Human-centered. As functionality and usability are directly related to the life of mobile applications, human-centered functions and interfaces are required to improve usability and functionality.

Generally, a conventional software development methodology cannot deal with these features of the MCE. Unlike the conventional methodology, agile seeks to accept changes in the middle of processes and to continuously communicate with project members, including customers and business members. Agile places the highest importance on delivering valuable software. Thus, the above features of MCE, except for the second characteristic, can be supported by the process and principles of the agile methodology. Consequently, in this study, we choose agile as the basic philosophy of our mobile software development methodology.

4.2. Agile and agent technology

As we mentioned, the software development process based on agile basically has iterative and evolutional processes to reflect requirement changes actively. Because of the rapid process, intensive labor and knowledge are required of developers, indicating that agile cannot solve the second aforementioned characteristic of MCE. In particular, the burdens on developers of the processes increase when they want to satisfy the additional adaptation requirements because adaptation includes a high-level information processing. Also, the rapid process repeats tests and inspections until the requirements are sufficiently met. Suppose we have a technical support on these burdening processes, and then we can reduce the load of knowledge engineering. In order to do that, the technical support has to possess the ability to collect widely spread information and to process collected information, like reasoning and knowledge processing. Agent technology has features that could supply those abilities and agility, as it is autonomous, reactive, and proactive [11, 12]. Agent operates on the basis of knowledge (e.g., belief-desire-intention agent model [13–17]). Thus, agent technology can support the burden process based on information collecting and processing.

4.3. MCE and agent-oriented software engineering

In the field of software engineering, there exists a study about controlling the complexity of complex software systems by abstraction, using the agent concept called AOSE [8]. In this study, systems are considered composite components with several sub-components recursively representing specific goals or objectives. Each component could be expressed as an agent, which is reactive, proactive, autonomous, and social. That is, the complex software system is an organic set of components operating autonomously to meet the objectives. In another study about controlling the complexity of software intensive systems through the agent-oriented approach, researchers said that there are remarkable improvements for some decomposable and organizational problems. Therefore, an agent-oriented approach for the MCE is beneficial. In addition, the features of an agent give flexibility and scalability to the system organization, which is needed to realize adaptation. Consequently, the AOSE approach reduces complexity and other potential abilities to adapt to the system.

Hence, in this research, we plan to apply the AOSE approach to mobile software engineering to control complexity. From AOSE viewpoint, the MCE includes elements related to mobile computing, like mobile devices, mobile software, users, and developers. Such an MCE is generally composed of various mobile elements, but is not apart from a conventional computing environment. Such components of MCE communicate mutually in sharing their services and information, and sometimes even collaborate and cooperate like family products. Thus, the architecture of MCE could be expressed as seen in Figure 2 which shows that an MCE is generally composed of user mobile environments and can be decomposed to smaller systems composed of mobile devices and applications.

Figure 2

The architecture of an MCE based on an agent-oriented approach.

As we discussed above, each of these three concepts has specific features, and these features have supplementary relations with each other as seen in Figure 3. In the MCE, requirements are easily changed, and frequent tests and revisions are necessary. Because of this, iterative implementation in the short term requires intensive labor and knowledge of developers. Furthermore, human-centered functions and interfaces are needed. Consequently, the loads of developers are the result of these busy processes and additional requirements of adaptation. Agent technology can support part of this load, specifically in the areas of knowledge engineering and inferences. Moreover, an agent-oriented approach can deal with the complexity of an MCE for mobile software engineering. Therefore, we plan to combine these three concepts in a hybrid approach to address the problems of mobile software engineering.

Figure 3

Relations of key ideas.

5. Body of methodology

The mobile software development methodology proposed by this research is to resolve the problems caused by the complexity and variability of MCE. The proposed methodology uses the flexibility of the agile methodology, the technical capacity of agent systems, and the abstraction of AOSE concepts. For designing such a methodology, we discuss four phases: principles, concepts, processes, and technical supports.

5.1. Principles

Though agile is generally used for mobile software development instead of conventional software development methodology, it does not focus on mobile software development. Thus, we need to reconsider the principles of agile from a mobile software development view, but as original agile principles are old-fashioned, we referenced recently proposed agile principles in an article by Williams [18]. The five principles, used by the proposed methodology, are selected from them. They are shown in Table 1. The principles in italics are the selected principles. Principle 9 was slightly revised to mention usability and functionality, which are necessary to consider during the process.

Table 1 Agile Principles as outlined from an article by Laurie Williams[5]

As stated in principle 1, the most important principle of mobile software development is delivering valuable software to users continuously in the short term. Flexible processes and willing minds are needed to accept dynamically changing requirements from various users. Mistakes and misunderstandings have to be reduced through frequent communication and specifications of important changes and feedback. During these steps, developers should pay attention to technical excellence and preserve usability in order to make the product valuable to users. Moreover, important change-centered documentation is pursued instead of heavy documentation. The ultimate purpose of these principles of mobile software development is to produce a human-centered application valuable to real users through flexible processes and active communications.

5.2. Concepts

We referenced several terms to explain certain concepts and artifacts within our process.

• Requirement elicitation. A method of eliciting requirements, which are based on the user's situation and context, for mobile software development.

• Conti. The material for description of a scenario composed of components like mobile software, agent, and external components. The material includes UI and view, data flows, and simple descriptions about the internal computation.

• Profile. Information used for figuring out the environment and users for adaptation. Profiles are composed of processed information and a data structure.

• Variable point. An asset differing in the behavior and its situation.

• Variants. Descriptions of required behaviors to make a choice for the next branch in variable point at the given situation.

• Feed report. A record of important changes and their results for feedback of each iteration.

5.3. Process

Basically, our mobile software development process is based on AOSE and follows agile principles. Our process includes an iterative process for the development of each component, and this manner can satisfy the dynamically changing requirements rapidly. As seen in Figure 4, our process of mobile software development starts from setting up the basis with ideas, categories, objectives and services of the system. The component is divided into simple mobile applications, sharable services, and agents. It could be evolutionally implemented through iterative processes. The initialization and test processes would be supported by agent technology in order to reduce the burden of information processing and repeated testing. Each step will be explained as follows.

Figure 4

The process of an agent supported mobile software development methodology based on agile.

5.3.1. Initialization

The initialization process includes idea generation and the requirement elicitation process to initiate the target system and its scope. Firstly, the mobile applications, which are chained with parallel usages, are derived through a survey about the status of mobile software usage. Such derived applications and requirements present the requirement that is reflected on the subconscious of users. Thus, the emerging requirement that users want to get is elicited through analyzing the requirements and implicit relations among the existing applications. Figure 5 represents this proposed method. Based on such emerging requirements, the target system will be settled, and ideas and the scope will be edited.

Figure 5

The emerging requirement elicitation.

5.3.2. Design architecture

After the initialization of a target system, we have to define the architecture of target system based on AOSE, composed of components that are described by specific objectives. From the predefined requirements of the target system, engineers find uncovered problem spaces and design a component that has specific objectives to solve the problem. Shared problems between components could be solved by defining a reusable service of the other components. In addition, an independent component could be added to solve the problem. Moreover, variable points and common points are described in this architecture based on SPLE concepts to explain which components are available for the change and which are not, as shown in Figure 6.

Figure 6

Designing architecture.

5.3.3. Decomposition and prioritization

The architecture is decomposed into segments and prioritized in order of development priority in several levels according to the relationships among the components. This step is to increase the reusability of each segment and understandability of the overall architecture and to respond to the dynamically changing environment and requirement more easily.

5.3.4. Iterations

For each component in a segment that is not developed yet, conventional software development process is repeated. During this phase, we reject weighted documentation in order to make progress rapidly, but we recommend simplified artifacts for specifying important changes, feedback, and progress.

5.3.4.1. Scenario

Based on the architecture of the target system, we have to define the exact scenario. In scenarios, the composition of the mobile application's elements, functional flows, and interactions among the elements is described. In the simple case of just one mobile application, we can draw the scenario as a flow of views and processes. In more complex case of composite applications, we can draw interactions among components with some objectives and functions. Here is an example of developing the family applications for a bank company. There should be some considerations of security, identification, and so on. Each of these parts could be divided into some smaller components. In addition, if there are plans for adaptation, then variable points and variants are also described in the scenario. Basically, the variability description is composed of a variable point and variants. Usually, variable points are caused by information processing as seen in Figure 7. In this case, for adaptation, the information analysis process could be replaced by the agent. At the end of this step, a conti is produced as a result. A simple example of conti is shown on the case study of this paper, in Figure 8.

Figure 7

A conti example for adaptation.

Figure 8

Conti for experiments.

5.3.4.2. Requirement analysis

In this step, the functional and non-functional requirements for each component are described. In particular, requirements for adaptation have to be described based on the distinct situation. Also, the attributes of agent, which is used in the target system, have to be preliminarily described for agent specification (e.g., reactivity, pro-activeness, social ability, and autonomy [9]).

5.3.4.3. Design

For every component in the prescribed scenarios and requirements, actual data and functional structure are defined. Components are specified by the features of the agent - generally goals and behaviors. Moreover, profiles about the system and users related to adaptation and functions should be designed for each adaptation plan, which is described in the previous step. Several kinds of profiles have to be designed for adaptation. The type of profiles could be distinguished as shown in Table 2.

Table 2 Type of profiles

General profiles include the shared information that could be accessed by all components. It usually includes the general information about users and the system that could be used to extract the implied information, like patterns or the context. This general information has to be provided by the mobile framework. If additional information is needed for the component's adaptation, then the restricted profiles will be designed for an extension of information.

5.3.4.4. Implementation

In this step, the designed components are implemented. This implementation is restricted to the previous design result. If new attributes or requirements occur in this step, the process needs to go back to design step. No functionalities, which are not described in design step, should be implemented. As this methodology is employing an agent module, the agent is also implemented in this step. This agent module is made using the predesigned specifications, models and platforms, and profiles.

5.3.4.5. Testing and feedback

For a present component, engineers verify the agent in a syntactic and semantic way. If it passes the formal test, then engineers will deliver the latest version of the component to users and collect reactions and feedback. At the end of this step, developers analyze artifacts of previous steps, and then make a choice whether they should go through iteration again or go over to the next iteration for the other components. During this phase, the agent-supported development environment could conduct the formal test on the components and collect the results of the testing and feedback instead of the team. Consequently, the specifications of changed requirements, the revisions for the satisfaction, and progress should be documented.

5.3.5. Verification and validation

For the target system operated by all working components, engineers must ensure the satisfaction of the original purpose and objectives they planned in the first step of this process. They also should check whether the combined target system is adapted in the predefined contexts.

5.3.6. Deployment and maintenance

After the above steps are done, the goal product is made. In this step, the deployment of the product and its maintenance are executed. To keep the usability of the product and satisfaction of users, the team has to make a window for continued communication with users and the changes of the market. If needed, they could go back to the iterations and do their process again.

When we comply with these described whole processes, some artifacts are made for each phase, as shown in Table 3.

Table 3 Artifacts of the process

5.4. Framework

Our mobile software development methodology includes technical agent supports to help the process of the adaptation and test. Agent technology can support information processing on the MCE. The supported environments are largely the development environment and the mobile software environment. As seen in Figure 9, the in-process information during the development and use of applications is collected and analyzed by information-managing components, and the newly produced information is used for developers to implement a new application and for mobile applications to adapt. This process of information collecting and processing can be executed in real-time by the help of the agent, who supports the information lifecycle. Thus, autonomous knowledge-based agent technology is appropriate to support these distributed real-time knowledge intensive processes.

Figure 9

The Framework for mobile software development methodology.

Consequently, previous principles, processes, and technical support compose the framework for developing a mobile software. As shown in Figure 9, our adaptive mobile software development framework adopts the simplified principles based on agile, the process of AOSE, and the agent technology support. The five principles of agile are well matched to the features of MCE and made iterative processes based on that. Each step of the process is based on the AOSE and is supported by an agent technology with labor- and knowledge-intensive processes. Moreover, we propose agent technology support adaptations of mobile software.

6. Case study

In this study, we have made an experiment referred to case study research design components [19] to show the effectiveness of an agent support and illustrate a way to take into account mobile user customization functions. Thus, we have planned two applications, which are to recommend new services according to the user's behavior history in the mobile environment. One was developed by the classic development methodology, and the other was developed by the proposed mobile software development process.

6.1. Objectives and propositions

This experiment has two main objectives. One is to show that the utilization of an agent support is valuable. The other is to show that the agent can actually reduce the complexity of the development process. Therefore, the following statements are considered in this experiment:

• Reflecting the user customization requirement;

• Reducing loads over the developers;

• Improving accuracy and functionalities.

Concerns for developing customization functions were reflected to the proposed process to make the process easier. Through agent support, we can reduce the loads on the information processing aimed at customization. Lastly, the accuracy and functionality will be improved through the capability of agent reasoning. The evaluation metrics for these propositions are shown in the next chapter.

6.2. Metrics

Table 4 describes the metrics and comparison of classic software development methodology with our proposed methodology. In this experiment, we have focused on the effectiveness of agent support. So, we have used four attributes in these metrics. These attributes are ‘level of difficulty’, ‘cost of time and labor’, ‘customization usability’, and ‘capability of information processing’.

Table 4 Metrics for evaluation of methodology

6.3. Experiment

In this experiment, we have made two applications. These applications have the same function which is to recommend new services to be used. One application is developed with agent support in managing intent map, and the other is developed without the support. In this section, we will explain the core concepts and results of customization.

6.3.1. Scenario

In the proposed methodology, we introduce some concepts for customization and adaptation requirements. Among them, we have adopted three concepts: conti, variable points, and profiles. Firstly, our program has a simple structure composed of three processes and just one view as seen in Figure 8. As you see in this conti, this scenario is composed of units in mobile applications. Generally, units of android applications are recognized as layouts or activities. However, the more general terms need to be used. Among these processes, the standard app list supply makes variability in this application. According to the information supplied by this process, the actual list of recommended services for the user is decided. Though it does not have visible variants, it has actual variability at that point. For the first application, a standard service list is collected from the user's mobile environment. For this, we used the list of present launched services beforehand. As the proposed methodology is used, this process is replaced by an agent module. In this experiment, application intent map agent, which has information about each service's user priority, is the agent module. Through this replacement, we can get more customized and meaningful information to be used as standard for extracting related services.

6.3.2. Design

As a part of the design, we defined two profiles: intent map and application relation map. An intent map is a kind of general system profile supplied by an application intent map agent. This profile is composed of applications, their counts of launch, and counts of launching dependency as seen in Figure 10. We implemented the agent to calculate the priority of the applications of the user based on a PageRank algorithm. The gray circle seen in Figure 10 represents the applications that have high priority and will be used as the standard for looking for related applications.

Figure 10

An intent map as a general system profile for experiments.

An application relation map is a kind of app-specific profile composed of applications with connections to each other as seen in Figure 11. The link between applications means that many users using one application can also use another application together. The former picture shows that the candidate has duplicate relations with some applications. The later one shows that the linear relation can be shown in a family product.

Figure 11

An application relation map as an app-specific profile for experiments.

Consequently, in the first experiment, we simply get the list of currently used applications as standards and then gather additional applications related to the standard applications, but in the second experiment, we use the agent computing with an intent map and make a list of most important applications to the user, instead of just utilizing the currently used applications list.

6.3.3. Results

Figures 12 and 13 show the results of our experiments. As seen in Figure 12, recommended applications are actually not usable for the users in some cases. Specifically, users who generally use the bank and card company applications also use another application showing arriving bus information. The services are recommended to this user at the given time. However, the wrong service, which is for C university students, is recommended to this user who is a student of A university. In Figure 13, for the second experiment, the application with agent support keeps the application that has a high probability of use at the top of the list.

Figure 12

Result of first experiment without agent support.

Figure 13

The results of a second experiment with agent support.

As a result, some concepts like conti, variable points, and profiles for customization and adaptation are reflected in the process of this experiment. Loads, by implementing the process extracting high priority applications from the user, are reduced using agents instead of people. Lastly, accuracy and usability of application have improved through the utilization of meaningful information from an agent. Consequently, in these experiments, we show three propositions, which are explained in Section 6.1.

Actually, these applications do not always recommend fantastic applications to the user. The reason is that the information is not enough to realize the taste of the user. The information about each service's user priority is not enough to make a practical user customization. However, we expect that it would be possible to get information and increase the accuracy of adaptation if the infrastructure is constructed to support an information lifecycle.

7. Discussion

In this research, we attempted to reflect the requirements of the MCE on the methodology and to solve the problems caused by variability, approaching from the hybrid method of combining agile software development methodology and agent technology to make the process effective. Also, we used concepts of SPLE and AOSE to control the complexity of engineering process and to facilitate the realization of adaptation. Lastly, we made experiments to show the potential of agent support in complex mobile developments, e.g., customizing and adaptive mobile software. However, we still have drawbacks in our process, which could yield to further studies as follows:

• Standard specification of agent for MCE for adaptation

• Autonomous agent verification and validation

• Evaluation of adaptive mobile software

• Realization of agent-supported development environment

• Agent-supported mobile software platform.

Moreover, mobile software engineering and an AOSE approach for customized/adaptive MCE are scarce. However, we are on the stepping stone to adaptive and tailored functions for user and environments. So if we face the needs of an adaptive MCE and the difficulties with complex mobile software engineering, then we could learn more about issues such as the following:

• Organization of components in MCE

• Collaboration between applications and mobile components in MCE

• Adaptation of mobile application and complex MCE

• Infrastructure to supply tailored service and information processing.

8. Conclusion

In this paper, we described the need for an agile-based software development methodology for dynamically changing requirements of mobile software in wireless networked computing environment. This approach can be used to provide automatic computation support for suitably decomposed tasks.

The proposed methodology includes these two features. One is the requirement discovery and the use of variable point concepts in SPLE for the representation of adaptive software requirements. The other is a process satisfying the changing requirements and accommodating the information lifecycle. In the designing of the methodology, we reflected the adaptation requirements as well as the constraints of MCE onto the methodology. Finally, using those concepts, processes, and technical support, we proposed a framework for mobile adaptive software development in wireless computing environment. Moreover, we also described the possible effects of agent support by performing two experiments.

As an experiment, we found a fragmentary scenario to understand the effect of agent support. From this test, we could realize the advantages of the infrastructure which supports the proposed methodology.

In short, what we would like to show in this paper are like these. One is a new mobile software development methodology, which reflects the feature of wireless computing environment. Another is the mobile software development framework based on hybrid solution of agile philosophy and agent technology. The other is the incorporation of ‘requirements discovery’ stage which is a new unit of mobile software development process to support the need of software adaptation. With these objects, the design of a human-centered software development methodology and framework for mobile software development in wireless computing environment is proposed in this paper.