COMPOOTIM: An Approach to Software Processes Composition and Optimization Andréa Magalhães Magdaleno1,3, Renata Mendes de Araujo2,3, and Cláudia Maria Lima Werner1 1
COPPE/UFRJ – Systems Engineering and Computer Science Department Zip 21945-970 – Rio de Janeiro – RJ – Brazil – P.O. Box 68511 2
Graduate Program in Information Systems – UNIRIO
3
NP2Tec – Research and Practice Group in Information Technology – UNIRIO
[email protected],
[email protected],
[email protected]
Abstract. Software process definition is a complex, time consuming and error prone activity. Such activity can be facilitated by a process reuse strategy. This strategy can be implemented through a context-based process line approach. Based on the data from this approach and following its systematic, this work presents a proposal to software processes composition and optimization (COMPOOTIM). The purpose is to support the project manager’s decisions and automate the composition of a project specific process. COMPOOTIM optimizes the suggestion of processes to the context of a particular project. A usage scenario for process selection exemplifies the use of COMPOOTIM. Keywords: Software process, process definition, process composition, process optimization, decision support, process line.
1
Introduction
Software organizations are continuously challenged by the need to improve the quality of software products. In this scenario, the assumption that the adopted software process directly influences the quality of the developed product [1] has motivated many organizations to invest in software processes definition. However, process definition initiatives are usually challenged by diversity in various levels. The diversity of organizations and projects makes the contexts in which processes are used very distinct. Considering that any two organizations are different, and that two projects within the same organization can also be different, there is no software process, no matter how well it has been defined, which can be generically applied [2]. This makes clear the statement: "Just as there are no two identical software projects, there are no two identical software processes in the world" [3]. As the universe of software projects is extensive, a single development model cannot satisfy all of them, because they have different goals and needs. The diversity
of software development models also challenges the process definition activity. Plan-driven [4], agile [5] and free/open source software (FOSS) [6] development models have the same goal: to improve software development, but they adopt different approaches. Plan-driven (such as CMMI) seeks for predictability, stability and reliability. Agile development (like XP and Scrum) tries to quickly add value to business and adapt to changes. In FOSS, the main objective is to guarantee users’ freedom, working collaboratively. Each model represents a distinct development universe, differing in philosophy and main characteristics. In order to establish more effective software processes, research in the area have discussed how to promote the reconciliation among these development models [7]. Process diversity occurs when a project is executed applying different processes. It may happen: (i) concurrently within the same project (latitudinal - observed in projects with different teams working in parallel); (ii) in software processes over time (longitudinal - the adoption of different processes throughout the lifecycle of a project, observed in the transition from development to maintenance stages) [8]. Finally, a process cannot be defined without considering people who will use it (such as employees of the organization) or interact with it (such as customers and suppliers). It is necessary to connect the process to people and establish how they work and interact [9]. The diversity of people involved and social interactions among them, adds a further challenge to the task of defining software processes. There is a growing need for the effective definition of software processes which can cope with this diversity [10]. Despite being one of the main tasks to be executed by the project manager, process definition is not simple. Such activity demands experience and knowledge from several aspects of Software Engineering. It also requires pondering many organizational factors (requirements, needs and goals) and evaluating a large set of constraints regarding project and team context. The manager is not usually able to evaluate all available combinations and often chooses a process in an ad-hoc manner, possibly selecting one that is not the best alternative for the current project. These decisions are usually taken once, early in the project, when there is not enough information to predict a totally appropriate process. Besides, the project context will change during its execution and the process should reflect it. In this scenario, process definition can be time consuming, error prone and causes the following negative consequences [2]: unnecessary activities that lead to a waste of time and money; the omission of necessary activities, which may affect the product quality; and the failure to comply with the organizational or international standards. In practice, process definition has two different approaches [4]: tailoring from the organizational standard process [2]; or process composition based on smaller and reusable units. This work is based on process composition through reuse structures, such as process lines [10–13]. These reuse structures have the potential to deal with process diversity or variability, help to disseminate knowledge and successful experiences, and adapt software processes for utilization in another context. In order to facilitate process composition, this work presents COMPOOTIM – an approach that supports project managers’ decisions about process components selection and combination and optimizes the suggestion of processes to the context of a particular project. The benefit is threefold. The idea of automating some of the steps reduces the effort and increases productivity in the process definition activity. At the same time, it can contribute to improve the quality and appropriateness of the
resulting process. Finally, it involves software processes adaptation to the reality of organizations, projects, and teams and the reuse of past and successful experiences. The remainder of this paper is organized as follows. In Section 2, a context-based process line approach is presented. The COMPOOTIM approach is described in Section 3. A usage example is detailed in Section 4. In Section 5, related work is discussed. Finally, Section 6 offers some concluding remarks.
2
Context-based Process Line
Software processes within an organization can be organized according to similarities and variabilities, allowing for a process composition based on specific project needs [12]. To organize these processes, a reuse structure – process line – can be adopted. A process line corresponds to the application of the product line [14] idea to processes. It can be understood as a set of processes in a particular domain, having common characteristics and being built based upon common, reusable process assets [13]. In a previous work of our research group [15], it was proposed to use context information to support process composition. Context is a complex description of the knowledge shared on physical, social, historical and other circumstances where actions or events happen in the real world [16]. Context management allows identifying modifications in a process at runtime in order to adapt it to new situations. Therefore, process composition must be continuously performed as more information is available during project execution, i.e., considering the process enactment context. Aiming to offer a systematic to support process composition and reuse, a contextbased process line (CBPL) [15] was created. CBPL corresponds to a set of process components, organized to represent common and variants parts within a specific domain that can be reused and combined, according to composition rules, to dynamically compose and adapt processes. The CBPL approach was similarly structured to the product line phases: Software Process Domain Engineering (SPDE) and Software Process Application Engineering (SPAE) (Fig. 1.). SPDE is performed by process engineer(s) when there is the need to establish an organizational process line; and when requirements, needs and goals change, promoting the evolution of the process line. Existing process and/or reference models serve as input to SPAE. These inputs are originated from two alternative strategies [12, 13]: bottom-up and top-down. In the first, existing knowledge in organizational process models or running instances of software projects are recovered to create the process line. In the other, process line starts from scratch, based on reference models. The top-down strategy, used as an example in this work, is most appropriate when there are no predefined processes in the organization or the goals for the creation of the process line are not clear. The SPDE phase creates the process line with a generic set of processes that captures the commonalities and variabilities in a domain. It makes explicit the points where these processes are similar and can be reused, and the points where they diverge, and need specific treatment. Variability in software processes becomes important in order to deal with diversity and adapt for use in a particular context. In SPDE, Analysis phase aims at identifying the domain knowledge through a feature model [17] (that represents domain characteristics, commonalities, and
variabilities of a process) and composition rules (that represent dependencies or mutually exclusive relationships). At Design, process architecture is specified to define the “skeleton” that a process must have, establishing the main components, their internal properties and interfaces, and how they relate to each other. Each feature has a set of components that implement a process. Implementation of the process architecture aims at generating executable models (Fig. 1.a).
Fig. 1. Context-based process line approach [15]
Regarding context, during Analysis, it is also possible to identify the contextual information considered relevant to describe the process. The context model represents the contextual knowledge and is composed of context dimensions and information [18]. At Design, context model is refined through context definitions (situations that may happen based on the combination of certain context information) and context rules (suggest process selection based on context definitions) [18]. Implementation involves the creation of a context repository (Fig. 1.b). After establishing the software process line in SPDE, for each project, instead of defining a process from scratch, project managers can make use of the process line infrastructure to compose a project specific process in SPAE. SPAE phase contains activities similar to those presented in SPDE (Fig. 1.c). First, at Analysis, the outcome is a cut of the feature model, containing only the features necessary for the new process. During Design, the process components are selected to be used within the architecture. From these inputs and the existing context, the new process is composed. Finally, Implementation comprises an analysis of supporting tools for process execution. As a result, the process is ready to run and to be adapted at run time. This work focuses on process composition to define a process to a specific project, which means that COMPOOTIM, presented in the next section, will support SPAE phase (Fig. 1.c). From the standpoint of COMPOOTIM, the role of SPDE is to
provide information about the organizational process line. Within SPAE, the key phases of this research are Analysis and Design, because it is precisely during these two phases that project managers need assistance to make decisions about the selection of features and composition of process components from the process line.
3
COMPOOTIM: Process Composition and Optimization
In order to facilitate the project manager’s decisions during process composition, this work presents an optimization-based approach (COMPOOTIM) (Fig. 2.). The idea is to automate some of the steps, possibly reducing the effort required to conduct this activity, improving the quality and appropriateness of the resulting process, and reducing the risk of the obtained process not being adequate and used in practice.
Fig. 2. COMPOOTIM approach
In SPAE, the process is composed by the project manager from the process line. It implies that the manager makes decisions associated to variation points - points in the process where one can decide what variants, among the available ones, will be chosen to be executed. However, the product line experience shows that this configuration can be time-consuming and expensive [19]. The same difficulties are expected for process composition, but we claim that COMPOOTIM can reduce this complexity. COMPOOTIM automates the composition of a process adherent to the current context, infers and suggests which process features or components are adequate. COMPOOTIM receives different datasets (process features and components, composition rules, context dimensions, information, definitions, and rules) from CBPL. All these data are analyzed and combined in search for a solution. It evaluates all of them in order to suggest some possibilities of processes for the project (Fig. 2.). The project manager receives additional information about context and constraints that influence each of the options. COMPOOTIM provides the project manager a basis for decision making since it allows to be considered a larger universe of factors and alternatives. Thus, it contributes by offering information that otherwise would be difficult to obtain and allowing the manager to analyze different solutions and consider the impact of each on the project. Despite the automation support, the project
manager has the final decision about the process that will actually be adopted. The COMPOOTIM approach consists of three main interconnected parts. The first one is the composition mechanism, implemented in Java using a MVC architecture in a standalone solution. It adopts different techniques, such as filtering, combination and sequencing. Context rules act as filters, discarding those process features and components that do not apply to the project and selecting those compatible with the project context. Thereafter, process components are combined according to composition rules obtaining a list of potential combinations of these components. Finally, the sequencing connects the formerly selected components, according to their required interfaces (input artifacts) and provided interfaces (output artifacts), resulting in one or more possible processes to be used in the project. The usage scenario, presented in the next section, partially illustrates the operation of this mechanism. The optimization mechanism searches a solution space with several candidates of resulting processes, trying to find the set of parameters for which the utility functions have a maximum (or minimum) value. The utility functions characterize what is considered a good solution and help to better understand the nature of candidate solutions. The initial computational modeling of this optimization-based problem [20] points to the use of a heuristic algorithm, like genetic algorithms (GA), to solve this problem. Since its initial version [20], this optimization mechanism has evolved. Currently, it is framed in a complete solution for process composition and considers not only the selection of process components, but also the process features. The NSGA-II [21] is the GA algorithm that was chosen to solve this problem. Its implementation is using JMetal framework [22] and generates suggestions of composed processes, according to the given parameters. Finally, the visualization mechanism is the presentation layer. It summarizes information about project and team (initial and current) context that influenced the suggestions of processes. It also describes the processes suggestions through the sequence of components. In addition, it provides indicators to one monitor the value of the characteristic that was maximized (or minimized).
4
A Usage Scenario
In this section, we discuss the application of COMPOOTIM through the description of a scenario using the Project Management discipline. This example focuses on the Analysis phases of CBPL, although not entirely limited to it in order to provide a deeper understanding of COMPOOTIM functioning.
4.1
Creation of a context-based process line
To illustrate the creation of a software process line, we developed an example, using a top-down strategy, based on some reference models (Scrum, XP, OpenUP, and RUP). Each of these models was analyzed and represented by an individual features diagram [23]. From this analysis, we chose the discipline of Project Management as example, because it is present in all these reference models and have a wide variation. From the individual models, the next step was the creation of a process line, integrating all these different models through the identification of optionalities and
variabilities. By having the same goal, the ArchToDSSA approach [24], originally created to define reference software architectures, was adapted to support the creation of a process line in a systematic and consistent way [23]. The resulting process feature model is partially presented in Fig. 3. This model uses OdysseyProcess-FEX notation [25] and was created with the aid of the Odyssey environment [26]. The process line defined for Project Management is composed by 1 discipline (Project Management), 7 activities, 35 tasks, and 14 products (omitted in the figure to keep its readability). These 57 elements are related through different types of relationships. The mandatory features are represented by a continuous line and optional features by a dotted line.
Fig. 3. Example: Project management process line
This feature model has two main activities: Project Planning and Project Monitoring, both mandatory. Project Planning is composed by Project Conception, Development of the Software Development Plan, and Iteration Planning. The Project Conception activity is optional which means that not every project needs a formal start. In addition, one should notice that usually the analyzed models work with two levels of granularity for project planning: project (consider the project as a whole) and iteration (focus on the work being done). Development of Software Development Plan has a high level of variability – the Estimate Project task can work with size, effort or cost estimations; and the Develop Project Plan task can include the creation of different plans, such as Problem Resolution, Quality Assurance, Metrics, and Risk Management (Fig. 3.). The same idea of different types of estimations is also present in Estimate Work tasks. In these variation cases, a project manager can choose the best options considering the project needs, when composing the process. Finally, in Iteration Management, the monitoring can be done on a daily or monthly basis and it can be more (as a report) or less (as a standup meeting) formal. From the process features, some examples of composition rules were created
(Table 1). The inclusive rule indicates that to Handle Exceptions and Problems, it is important to also have a Problem Resolution Plan. The exclusive rule indicates that when Conduct Daily Meeting is selected, Monitor Project Status must be excluded, because they are redundant. The rules are highlighted in process features (Fig. 3.). Table 1 – Examples of features composition rules
Antecedent
Type
Consequent
R
#
Handle Exceptions and Problems
Inclusive
Develop Problem Resolution Plan
X
Conduct Daily Meeting
Exclusive
Monitor Project Status
In SPDE, it is also required to define the context model, including context dimensions and information. As a starting point, Araujo et al. [27] suggest nine context dimensions for the software domain. We are particularly interested in the organization, project and team dimensions, because of the diversity in these levels. For each of them, some examples of context information are presented in Table 2. This initial set of context information has been obtained from a literature review and validated through a survey with experts [28]. Table 2 – Examples of context information
Dimension Organization Project Team
Context Information Organizational structure, Organizational culture, Knowledge management, and Business objective Customer relationship, Size, Complexity, Novelty, Criticality, Duration, and Requirements stability Team size, Domain experience, Technical experience, Work together experience, Proximity, and Stability
From the understanding of this context information, the next step is to establish context definitions. Some examples (Table 3) were created to characterize common situations that impact the software process domain [28]. Context rules can specify the actions to be taken for a given situation. They represent how a context situation impacts on the configuration of a software process. The established context rules (Table 4) relate the context situations (Table 3) to features of the process line (Fig. 3.). This last step concludes the creation of the process line. Table 3 – Examples of context definitions
Definition Conservative organization Learning team
Expression Organizational structure = Very complex OR complex AND Organizational culture = Very formal OR formal Domain experience = Medium AND Technical experience = Medium AND Work together experience = Medium
Centralized team
Proximity = Centralized
Typical project
Complexity = Medium AND Criticality = Medium AND Size = Medium AND Duration = Medium
Both the feature and the context model are modeled and maintained with the support of the Odyssey environment [26]. The use of this information by COMPOOTIM and the resulting process are the topics of the next section.
Table 4 – Examples of context rules
#
Definition
Feature
CR1
Conservative organization
Implies
CR2
Centralized team
Implies
CR3
Experienced team
Implies
CR4
Learning team
Implies
4.2
Prepare Monthly Report AND Conduct Individual Management Assessment AND Develop Risk Management Plan Conduct Daily Meeting Choose Tasks Define Team and Project Structure AND Assign Responsibilities AND Schedule and Assign Work
Use of a context-based process line
Suppose a situation in which a new software project, called CDSOFT, aims to create an innovative product in the health domain. Due to product novelty, it has volatile requirements. Because of this instability, the documentation quickly becomes obsolete and the need for sharing knowledge among team members is intensified. In SPAE, the project manager needs to define a process specific to this project using the organizational process line presented in the previous section. The first step is to characterize the project context, by assigning values to context information in COMPOOTIM. Table 5 summarizes the CDSOFT context, registered by the project manager, according to the context information suggested in Table 2. Based on the project context and all the datasets generated in SPDE, the COMPOOTIM will help the manager to compose a project-specific process. It starts discovering current project context situation from the combination of the project context information (Table 5) and the predefined context definitions (Table 3). Thus, CDSOFT is characterized as follows: (i) conservative organization; (ii) learning team; and (iii) centralized team (Fig. 4). It does not fit in “typical project” situation, because CDSOFT complexity is High and not Medium. Table 5 – CDSOFT context information
Dimension Organization
Project
Team
Context Information Organizational structure Organizational culture Size Complexity Novelty Criticality Duration Requirements stability Domain experience Technical experience Work together experience Proximity
Value Very complex Very formal Medium High High Medium Long Low Medium Medium Medium Centralized
Then, it infers, based on context rules (Table 4), and suggests some process features that must be present in the resulting process: (i) Prepare Monthly Report; (ii)
Conduct Individual Management Assessment; (iii) Conduct Daily Meeting; (iv) Develop Risk Management Plan; (v) Define Team and Project Structure; (vi) Assign Responsibilities; and (vii) Schedule and Assign Work. Next, the composition rules (Table 1) are applied and the second one excludes the Monitor Project Status task. There are also some decisions about variabilities configuration and optionalities that the project manager will make based on his/her perception. For instance, the project manager can: choose which kind of estimation s/he prefers to use (such as effort); decide not to have a formal start or closure in the project; and opt to work with a minimum of activities, i.e., without unnecessary plans and revisions.
Fig. 4. CDSOFT context situations identified by COMPOOTIM
As a result, the composed process fits the enactment context. The resulting features model to CDSOFT project is presented in Fig. 5. These features will also influence the selection or exclusion of the related process components. The next steps consist of process components sequencing and optimization. Then, the process can be instantiated. During process execution, the project manager, helped by the automated monitoring mechanism, can constantly verify if the project’s context has changed. So the manager can decide to dynamically adapt the process (in the course of the project) by replacing process features or components.
Fig. 5. CDSOFT specific process features modeled in Odyssey
5
Related Work
The work of Martínez-Ruiz et al. [29] is closely related to this work, because it applies rationale management to support decision making when tailoring processes. However, our work differentiates by adopting a strategy of processes composition and reuse, instead of tailoring. In addition, the use of rationale management can help to share the knowledge about process definition, but they apply brute force and do not propose mechanisms to automate it. Two closely related areas are contingency factors and Situational Method Engineering (SME). Contingency factors [30] refer to variables that characterize a project to determine the selection of an appropriate method from a portfolio. This idea of project characterization is similar to the one proposed in this work and some of these factors were even used as context information. However, this idea was expanded: as part of a context management approach, it offers a greater dynamism in the selection of processes and also allows to consider the team and organization context. Furthermore, there is a lack of guidelines on how the contingency factors relate to the development methods [31]. This limitation is overcome in our work through the use of context rules that relate context definitions to process features or components. The area of SME [32] is intended to provide organizations with flexibility in configuring a project-specific process, using methods or fragments stored in a repository. SME also proposes facilities for this process configuration. This support and the existence of a range of process knowledge are similarities that approximate COMPOOTIM approach to SME. However, one fundamental problem is that the project manager needs assistance to make decisions about the process to be adopted in the project. While SME can present all the details about each individual process fragment, it gives no indication about the selection and combination of them to guarantee that the resulting process is completely usable. The capacity to compose this process, considering the project context, is a contribution of COMPOOTIM. SME and contingency factors can be combined to select methods according to the project context. In the present work, the idea is not to identify one method that can be used in its entirety, but to compose a process using features and components from a process line that was created based on different development models. Despite the existence of proposals that deal with parts of this solution, like process lines [10–13] or automation of features selection in product lines [33], they do not tackle the problem with a complete, integrated, and dynamic solution as in this work.
6
Conclusion
This work presented the COMPOOTIM approach, which represents a complete solution for process composition and optimization. The main idea is to support project managers’ decisions by automating and optimizing features and components selection in the process composition activity. A usage scenario for process selection exemplifies the behavior of COMPOOTIM. This example focused on process features at Analysis, but can be amplified to reach the Design activity and explore process components.
As a result of COMPOOTIM application, it is expected that the complexity and effort required for process composition is reduced. Hollenbach and Frakes [34] show that it is possible to reduce by at least ten times the time and effort needed to define a project-specific process when the process is reused instead of creating it from scratch. However, this work also has some limitations. The composition and optimization mechanisms consider some constraints like sequencing, components relations, and artifacts, but agents (or actors) allocation issue is not addressed. In addition, some mechanisms to validate rules and check consistency may be necessary. Although the process line used in the example has been created using real reference models and following a systematic, it was only explored as an example, without being validated with specialists or testing proposal scalability. On the other hand, this knowledge base is already organized and available in COMPOOTIM to exercise the optimization algorithms. As future work, there is a plan to define a software processes line in a real organization with the participation of the software process definition group. As future work, we intend to conclude the development of COMPOOTIM. It is also planned to validate, through experimental studies: (i) the influence that each context information has on the quality of the generated solution; (ii) correlations between context situations and software process features or components; (iii) if the resulting process is better than one that would be composed without the proposed solution; (iv) solution applicability in real software developments by conducting some case studies. These validations will provide useful feedback to improve the approach.
Acknowledgments This work is partially funded by CNPq (under processes nº. 142006/2008-4 and 310776/2009-0).
References 1.
Fuggetta, A.: Software process: a roadmap. Proceedings of the Conference on The Future of Software Engineering, pp. 25–34, ACM, Limerick, Ireland (2000).
2.
Pedreira, O., Piattini, M., Luaces, M.R., et al.: A systematic review of software process tailoring. SIGSOFT Software Engineering Notes. 32, 1–6 (2007).
3.
Humphrey, W.S.: Managing the Software Process. Addison-Wesley, Boston, MA, USA (1989).
4.
Chrissis, M.B., Konrad, M., Shrum, S.: CMMI: Guidelines for Process Integration and Product Improvement. Addison-Wesley, Boston, USA (2006).
5.
Beck, K., Beedle, M., Bennekum, A. van, et al.: Manifesto for Agile Software Development, http://agilemanifesto.org/.
6.
Raymond, E.S.: The Cathedral & the Bazaar. O’Reilly Media (2001).
7.
Magdaleno, A.M., Werner, C.M.L., Araujo, R.M.: Reconciling Software
Development Models: A Quasi-Systematic Review. Journal of Systems and Software (JSS). 85, 351–369 (2012). 8.
Siebel, N.T., Cook, S., Satpathy, M., et al.: Latitudinal and longitudinal process diversity. Journal of Software Maintenance. 15, 9–25 (2003).
9.
Swenson, K.D., Palmer, N., Kemsley, S., et al.: Social BPM. Future Strategies Inc (2011).
10. Aleixo, F.A., Freire, M.A., Santos, W.C., et al.: A Model-Driven Approach to Managing and Customizing Software Process Variabilities. International Conference on Enterprise Information Systems (ICEIS), pp. 92–100, Funchal, Madeira, Portugal (2010). 11. Barreto, A., Rocha, A.R., Murta, L.: Supporting the Definition of Software Processes at Consulting Organizations via Software Process Lines. International Conference on the Quality of Information and Communications Technology (QUATIC), pp. 15–24, Porto, Portugal (2010). 12. Rombach, D.: Integrated Software Process and Product Lines. Unifying the Software Process Spectrum, pp. 83–90, Springer-Verlag, Heidelberg (2006). 13. Washizaki, H.: Building Software Process Line Architectures from Bottom Up. Product-Focused Software Process Improvement (PROFES), pp. 415–421, LNCS, Amsterdam, The Netherlands (2006). 14. Northrop, L.M.: SEI’s software product line tenets. IEEE Software. 19, 32–40 (2002). 15. Nunes, V.T., Werner, C., Santoro, F.M.: Context-Based Process Line. International Conference on Enterprise Information Systems (ICEIS), pp. 277– 282, Funchal, Madeira, Portugal (2010). 16. Brezillon, P.: Context in problem solving: a survey. Knowledge Engineering Review. 14, 47–80 (1999). 17. Kang, K., Cohen, S., Hess, J., et al.: Feature-Oriented Domain Analysis. CMUSEI (1990). 18. Fernandes, P., Werner, C., Murta, L.G.P.: Feature modeling for context-aware software product lines. International Conference on Software Engineering and Knowledge Engineering (SEKE), pp. 758–763 (2008). 19. Deelstra, S., Sinnema, M., Bosch, J.: Product derivation in software product families: a case study. Journal of Systems and Software (JSS). 74, 173–194 (2005). 20. Magdaleno, A.M.: An optimization-based approach to software development process tailoring. PhD Track - International Symposium on Search Based Software Engineering (SSBSE), pp. 40–43, Benevento, Italy (2010). 21. Deb, K., Pratap, A., Agarwal, S., et al.: A fast and elitist multiobjective genetic algorithm: NSGA-II. IEEE Transactions on Evolutionary Computation. 6, 182– 197 (2002).
22. Durillo, J.J., Nebro, A.J., Luna, F., et al.: JMetal: A Java Framework for Developing Multi-objective Optimization Metaheuristics. Dept. de Lenguajes y Ciencias de Computacion, Univ. Málaga (2006). 23. Magdaleno, A.M., Werner, C.M.L., Araujo, R.M.: A Criação de um Exemplo para Alimentar a Abordagem COMPOOTIM de Composição e Otimização de Processos de Software. PESC-COPPE, Rio de Janeiro, RJ, Brasil (In Portuguese) (2011). 24. Vasconcelos, A., Werner, C.M.L.: Architectural Elements Recovery and Quality Evaluation to Assist in Reference Architectures Specification. International Conference on Software Engineering and Knowledge Engineering (SEKE), pp. 494–499, Boston, MA, USA (2007). 25. Teixeira, E.N.: OdysseyProcess-FEX: Uma Abordagem para Modelagem de Variabilidades de Linha de Processos de Software. Master Thesis. COPPE/UFRJ (In Portuguese), Rio de Janeiro, RJ, Brasil (2011). 26. ODYSSEY: Odyssey SDE Homepage, http://reuse.cos.ufrj.br. 27. Araujo, R.M. de, Santoro, F.M., Brézillon, P., et al.: Context Models for Managing Collaborative Software Development Knowledge. Workshop on Modeling and Retrieval of Context (MRC), pp. 61–72, Ulm (2004). 28. Leite, A.M.S.: Modelo de Contexto para Adaptação de Processos de Software. Master Thesis. PPGI–UNIRIO, Rio de Janeiro, Brazil (In Portuguese) (2011). 29. Martínez-Ruiz, T., García, F., Piattini, M.: Managing Process Diversity by Applying Rationale Management in Variant Rich Processes. Product-Focused Software Process Improvement, pp. 128–142, Springer (2011). 30. Bekkers, W., van de Weerd, I., Brinkkemper, S., et al.: The Influence of Situational Factors in Software Product Management: An Empirical Study. International Workshop on Software Product Management (IWSPM), pp. 41–48, Barcelona, Catalonia, Spain (2008). 31. Kumar, K., Welke, R.J.: Methodology Engineering: a proposal for situationspecific methodology construction. Challenges and strategies for research in systems development, pp. 257–269, John Wiley & Sons (1992). 32. Brinkkemper, S.: Method engineering: engineering of information systems development methods and tools. Information and Software Technology. 38, 275– 280 (1996). 33. Benavides, D., Trinidad, P., Ruiz-Cortés, A.: Automated Reasoning on Feature Models. International Conference on Advanced Information Systems Engineering (CAISE). 3520, 2005 (2005). 34. Hollenbach, C., Frakes, W.: Software Process Reuse in an Industrial Setting. International Conference on Software Reuse (ICSR), pp. 22–30, IEEE Computer Society (1996).
