Contextual Injection of Quality Measures into Software Engineering Processes
Gregor Grambow and Roy Oberhauser
Computer Science Dept. Aalen University, Germany
{gregor.grambow, roy.oberhauser}@htw-aalen.de
Manfred Reichert
Institute for Databases and Information Systems Ulm University, Germany
Abstract—Despite improvements in software engineering processes and tools, concrete preventative and analytical software quality assurance activities are still typically manually triggered and determined, resulting in missed or untimely quality opportunities and increased project overhead. Quality goals, when defined, lack holistic environmental support for automated performance measurement and governance that is tightly integrated in the low-level operational software engineering processes. This results in higher quality risks and cost risks. Based on adaptive process management, an approach is presented that injects situationally-determined quality measure proposals into the concrete workflows of software engineers, using contextual semantic knowledge and multi-agent quality goal tracking and decision-making. Our evaluation shows the feasibility of the approach for automatically providing timely quality measure guidance to software engineers without disrupting their current activities. This supports process governance while reducing quality risks and costs during software development projects.
Keywords-software quality assurance; process-centered software engineering; adaptive process management; semantic technology; agents; Goal-Question-Metric technique
I. INTRODUCTION
This article extends our previous work in [1], which described aspects of an approach for automated integration of software quality management and software engineering process management. Today IT-supported business process management (BPM) enjoys wide industrial adoption [2] and can support improved product quality by ensuring that quality-supporting processes are executed [3]. Process repetition and predictability lowers the recovery risk for necessary investments in process modeling, process management system support, and enterprise application integration [5]. Interestingly, BPM is also increasingly being used for product development [4].
In the software engineering (SE) domain, numerous obstacles inhibit automated SE process management (SEPM) at the operational level. These include the contextual dependency of the low-level activities (e.g., coding, debugging, testing), the high degree of change to the involved artifacts (e.g., source code files, test documentations), the informational and environmental dependencies (e.g., coordination, requirements, reports, tools), the uniqueness of each developer’s concrete personal
process (e.g., junior vs. senior engineers, information needs), activity coordination with the overall team process, the contextual and project influences on the processes (e.g., schedule, resource availability), and software quality assurance (SQA) dependencies (e.g., quality plan, reactive quality measures, metric dependencies).
Historically software development projects have also faced difficulties in meeting budget, schedule, functionality, and quality targets [6][7][8]. A more recent study in 2002 by the National Institute of Standards and Technology (NIST) found that most delivered software products are still stricken by bugs and defects [9]. While some of these difficulties might be ascribed to a misaligned planning environment in certain organizations [10], the project pressures and resulting issues will likely linger due to global competition and other influences [11]. Other difficulties can be attributed to SE’s adolescence as a discipline and certain unique product properties that affect the SE development process, such as software’s complexity, conformity, changeability, and invisibility [6]. Additionally, the extent (too little or too much) and timeliness of SQA significantly impacts overall project costs [12], making effective and efficient SQA vital. Yet it remains laborious to manage and apply the appropriate low-level SQA measures (actions) in a timely fashion during SE process enactment. In order to achieve software quality goals, these must be defined and concretely and contemporaneously measured [13]; yet this is often challenging for various SE organizations [14]. Especially small and medium sized companies often struggle to achieve high quality levels. This often results from the increased complexity of their growing organizational structures, the lack of process maturity and capabilities, and the lack of dedicated quality management personnel.
A. Problem Statement
While SE process models foster development efficiency [15], they are often defined rather abstractly and thus fail to provide low-level guidance for the activities actually executed at the operational level. Furthermore, processes are often defined rigidly beforehand. However, during their execution, reality often diverges from the planned process [16].
Automated guidance for combining SQA with SEPM is not yet prevalent. Challenges in software development projects are presented at both the product and process levels based on the nature of software artifacts and manually driven processes. Product intangibility hinders effective retrieval of
timely information about its product quality status. Additionally, the combination of abstract process definitions and intertwined, contextually information-dependent lower-level workflows make targeted process guidance for developers irrelevant, complex, or financially infeasible. Thus, artifact issues often cannot be detected promptly and, even if they are, the contemporary integration of quality measures into the workflow is not possible. At times, quality measures come into focus and are applied close to release, or, when the project is behind schedule, they may be jettisoned altogether; however, it is generally acknowledged that their application in earlier development stages saves time as well as money [12][17]. The proper application of quality measures is also problematic, since their effectiveness and efficiency depend on many factors, such as the applicability of the measure, the project timing, worker competency, and correct fulfillment [12]. For clarity, measure in this article is meant in the sense of a specific action intended to produce some effect - reactive actions are thus countermeasures.
To illustrate the problem as well as the proposed solutions, this paper uses a series of simplified practical scenarios dealing with a fictional company (called ‘the Company’).
Example 1 (Abstract Process): The Company uses a SE
process model for software development, the V-Model XT [18]. This process features detailed descriptions of activities, roles, milestones, and artifacts. Its application is based on the use of various documents with no automated governance or support. In the Company, activities for developers are planned and scheduled on a very coarse-grained level, leaving the coordination of what is to be done to the developers and manager. Therefore, the SE process does not really “touch” the developers, and their actual activities are difficult to trace. The quality of the source code is not monitored continuously and static code analysis tools are only used sparsely by the developers. Deterioration of the source code quality goes undetected and quality measures are only taken at the end of projects when there is time left or when concrete bugs exist.
B. Contribution
Automated support for and governance of the coordinated integration of SQA in SEPM offers promising perspectives for addressing shortcomings in current SQA approaches. In the following, the terms process and
workflow will be used extensively, and are delimited here against each other in alignment with existing definitions provided by the Workflow Management Coalition [19] and Gartner Research [20].
Definition: Business Process Management deals with the explicit identification, implementation, and governance of processes as well as their improvement and documentation. This incorporates different issues such as organizational or business aspects, or the strategic alignment of the activities. Workflow Management, in turn, deals with the automation of business processes. Hence, a workflow is the technical implementation of a business process or a part of it.
In our previous work, we introduced the CoSEEEK framework [21], which utilizes various technologies to provide automated, context-aware assistance for SEPM. In [22] and [23], we provided a solution to dynamically generate workflows according to the properties of various situations to support dynamic workflows extraneous to the SE process. We are currently also working on the integration of this dynamic generation with workflows belonging to the SE process and covering situations where pre-planned workflows are too rigid. In [24], we introduced an SE workflow language that provides extended modeling capabilities for SE workflows and improves the connection between abstractly defined processes and concretely executed activities. Finally, in [1] and [25], which provide the basis for this article, we described aspects of our overall approach for integrating SQM and SEPM. In particular, this paper provides a more comprehensive description of this approach with further extensions, in particular elucidating the following areas:
- automatic detection and management of source code related problems in a SE project,
- automatic assignment of quality measures to detected quality problems,
- automatic strategic prioritization and alignment of quality measures to project quality goals,
- tailoring of measure (action) proposals to the situation, and
- automatic integration of quality measures in the software engineer’s workflow.
The remainder of this paper is organized as follows: Section II presents background information needed for the understanding of this paper and elicits fundamental requirements for our solution approach. Section III describes our solution approach. Section IV discusses realization aspects and Section V evaluates our solution. Finally, Section VI discusses related work and Section VII concludes the paper.
II. REQUIREMENTS
Requirements have been elicited based on various sources we found in literature. The identified requirements cover different areas to enable comprehensive system support for integrating SQA and SEPM.
Context-awareness. To enable automated decisions on quality measure assignments, any system support should be aware of its environment and the context of the current situation.
Requirement R:Ctx1 (Context integration): To be aware of problems in the SE project, the system must have a facility to integrate information on SE process or product problems from various sources (e.g., external tools measuring the state of the source code, bug tracking systems).
Requirement R:Ctx2 (Quality opportunity awareness): To enable automated integration of quality measures at run-time, the system must be aware of quality opportunities, meaning time points when a user can cope with a quality
measure. This requires knowledge about the users' schedule, meaning the abstract activities that have been scheduled and estimated for the user.
Process management: To enable the automated integration of quality measures, the system must be able to govern the SE process automatically. To foster this in SE, facilities must be in place to enable the system to match the workflow specification belonging to the process (or parts of it) with other facts representing the current situation. That way, contextual information can be used for SE process support.
Requirement R:Sepm1 (Vertical workflow connection): It should be possible to define flexible connections between different workflows (meaning the vertical connections between sub-workflows and their super-workflows). In traditional process management, a simple connection between sub- and super-workflow is possible. If an activity of a super-workflow refers to a sub-workflow, it will be only finished at run-time after completing the corresponding sub-workflow instance. However, in practice, more complex connections may be required as illustrated in Figure 1 and confirmed by processes from other domains like the automotive industry [26] and enterprise resource planning [27]. In this example (Figure 1), activities are grouped by work packages. In the planning phase, for example, the packages and their corresponding activities are planned. This means that the activity of planning a package depends on the completion of the planning of the contained activities. The same applies for the processing of a package. That way there are multiple connections between the super and the sub-workflow, and the completion of a certain activity does not necessarily depend on the completion of a whole sub-workflow, but on the completion of one or multiple activities in one or multiple other workflows.
Figure 1. Sub-workflow Connections.
Requirement R:Sepm2 (Task Granularities): For the automated detection of quality opportunities, an explicit connection between abstract assignments, which have been planned and scheduled, and the related concretely executed activities is desirable. Traditional BPM features human tasks only with one single granularity. In fact, human tasks exist on different levels of abstraction that are often related to each other (see also [28][29]). Process management lacks sufficient support for this - just modeling tasks on different levels of abstraction does not adequately match reality since tasks usually have different properties. An example of those tasks is shown in Figure 2.
Example 2 (Task Granularities): Task 1 is an abstract assignment, which was planned and estimated from the business side. That task implies Tasks 2 and 3, which are concretely planned and executed by the developer. Those tasks, in turn, also imply tasks on a more concrete level like Tasks 4, 5 and 6, which may have special connections to the environment, as they require, for example, certain tools.
Figure 2. Task Granularities.
Requirement R:Sepm3 (Workflow adaptation): The concrete workflows should be adaptable. In particular, their specification should support automated adaptations during run-time to enable the system to automatically and dynamically insert quality activities into workflows where required and favorable.
Quality Measure Selection. The selection of appropriate quality measures during SE process execution constitutes another challenge. Various factors must be taken into account for effectiveness and efficiency.
Requirement R:Qmsel1 (Quality measure selection): Applied quality measures should be automatically chosen during run-time in alignment to project goals in order to match the defined strategy of the project.
Requirement R:Qmsel2 (Proactive measures): Quality measures should not only rely on detected problems, but also consider common quality enhancement. Thus, proactive and reactive measures should be available.
Requirement R:Qmsel3 (Situational measure tailoring): Context-sensitive tailoring of proposed measures is desirable considering different factors of the actual situation, e.g., properties of the applying person and application time point.
Requirement R:Qmsel4 (Measure assessment): The selection of measures should be aware of their effectiveness to optimally match with specific environments or situations in different companies. Therefore, continuous monitoring of the quality of the source code is essential to detect potential impacts of applied measures on the overall quality. In particular, a relation between the application of SQA measures and the evolution of source code quality should be established to assess the effectiveness of the measures.
III. SOLUTION APPROACH
Considering the aforementioned requirements, the concepts behind our solution approach are now described in detail. To automatically integrate quality measures into the SE process, our approach consists of a process (referred to here as a procedure to avoid confusion with SEPM) in conjunction with the architecture of the Context-aware Software
Engineering Environment Event-driven frameworK
(CoSEEEK) [21].
A. Solution Procedure
Our solution procedure involves three fundamental phases: a detection phase, a processing phase, and a post-processing phase as shown in Figure 3. These phases as well as their different steps will be explained in the following subsections.
Figure 3. Conceptual Procedure.
The Detection Phase continuously enables an awareness of the current project situation to meet the requirements relating to context-awareness (cf. Section II.B). For integrating quality measures, two factors are of particular interest: the presence of problems (cf. Requirement R:Ctx1) - recognized via the ‘Problem Detection’ - and the availability of opportunities for quality measures in the users’ schedule (cf. Requirement R:Ctx2) - recognized via ‘Quality Opportunity Detection’. To enable such detection in an automated fashion, the SE process specification must be extended (cf. Requirement R:Sepm2). The applied extensions will be described in Section III.C.
The Processing Phase deals with the selection and proposal of the quality measures and involves four steps. Utilizing the GQM technique [30], quality measures (actions) are initially proposed in alignment with project goals to satisfy Requirement R:Qmsel1. This phase also adds proactive measures to the measure proposal process (cf. Requirement R:Qmsel2). To prepare these measures for their automated application, ‘Measure Tailoring’ incorporates information about the applying persons and the possible points in the users' schedule in which to apply the measure
(cf. Requirement R:Qmsel3). This leads to a selection of appropriate points (so called Q-Slots) and to an automated integration of the quality measures into the concrete workflow of the chosen person. The application of measures can be also done automatically utilizing extensions made to the SE process specifications (cf. Requirement R:Sepm3). These enable the system to be aware of matching extension points (e.g., in the workflows). These are illustrated in Figure 4 by a small abstract workflow containing the activities ‘A1’ to ‘A5’. ‘A2’ and ‘A4’ have an associated extension point, meaning that an automated insertion of a new activity is possible subsequent to these activities.
Figure 4. Extension Points.
Finally, to be able to track the quality of the project continuously, in the Post-Processing Phase (cf. Figure 3) a ‘Measure Assessment’ is performed via a quality trend analysis. This analysis supports an awareness and automatic assessment of the potential utility of the applied measures, fostering quality (cf. Requirement R:Qmsel4).
Since each project is unique, the applicability and effectiveness of measures can vary with respect to different projects. Therefore, the system executes an assessment phase to rate the applied measures and to incorporate their impact in the given project.
B. Conceptual Architecture
CoSEEEK provides the necessary infrastructure for realizing the solution procedure presented in the previous sub-section. Its conceptual architecture is shown in Figure 5.
Figure 5. CoSEEEK Conceptual Architecture.
SE Tools is a placeholder for all tools used in a SE project of which CoSEEEK is aware, such as source control systems or IDEs. Artifacts are those things produced in a SE project using the SE Tools. This includes source code artifacts, documents, and models.
Awareness of changes to the state of tools as well as artifacts is supported by the Event Extraction module. It utilizes sensors that are typically integrated into the tools or otherwise monitor the tools. These sensors generate events in in response to various situations (e.g., 'switch to debug
perspective' in an IDE). The Data Storage module encapsulates the storage mechanisms for events and shared data. Communication is event-based and loosely coupled to support integration and exchangeability of different modules. The events generated and collected in the Event Extraction module are basic and low-level. The Event Processing module utilizes complex event processing (CEP) [31] to process these events, providing high-level events with enriched semantic value. The Rules Processing module uses rule-based computing to analyze tool data such as static analysis reports or metrics, and it triggers follow-up actions as necessary (e.g., quality measures for violated metrics). These triggered measures are subsequently filtered by the
AGQM (Automated Goal Question Metric) module, which automates and extends the GQM approach via multi-agent computing to analyze the project quality state in alignment with strategic project goals and to propose appropriate proactive and reactive quality measures.
The Process Management module applies dynamic and adaptive process management technology to govern the activities of the involved project participants. This enables the system to match workflows to real project situations (instead of rigidly prescribing certain activities and their orders) and thus provides real situational guidance. This becomes possible by utilizing the cumulated knowledge contained in the Context Management module. In that module, high-level information of all project areas is collected, as, for example, the skills of users or information about the quality state of the project. Using semantic technology, this information can be used to reason about the project state and contextual influences (causes and effects) and thus provide automated decisions and workflow adaptations such as the automated and dynamic integration of quality measure activities during SE process execution.
C. Context-aware Business Process Management
To support a high degree of automated and context-aware assistance, a tight coupling of the Context Management and the Process Management module is required, which will be referred to as Context-aware Process Management (CPM). This addresses many of the shortcomings of traditional BPM (as listed in Requirements R:Sepm1 to R:Sepm3) and facilitates the comprehensive utilization of the awareness capabilities in CoSEEEK. Fundamentally, process management concepts are enhanced with semantic information. This additional information is stored in the
Context Management module, while the workflows are managed by the Process Management module. Since Context Management unifies all project knowledge, it can be also used as a management layer around the Process Management module, facilitating context-based process management. Thus, all process-related actions are addressed by the Context Management module, which, in turn, manages the actions of the Process Management module. Figure 6 illustrates these extensions to process management.
The Process Management module governs the workflows and their activities. These two concepts are mirrored in the
Context Management module: the activity by the Work Unit
and the workflow by the Work Unit Container. Thus, process
management is separated into two areas that we call vertical
and horizontal process management. Horizontal process management denotes the governing of the different activities of one workflow (also denoted as process orchestration) utilizing well-established workflow patterns like AND, SPLIT, or LOOP. This is done within the Process Management module. Vertical process management, in turn,
deals with the management of the dependencies between different workflows on different levels of abstraction. Since process management only offers one kind of connection (an activity depends on a sub-workflow) here, this is handled by the Context Management module. This allows for the flexible definition of dependencies. The completion of a
Work Unit can depend upon one or multiple Work Unit Containers or on one or multiple Work Units contained in other Work Unit Containers. A mixture of both is possible as well.
Figure 6. Context-aware Business Process Management.
Work Units are connected to three other concepts, enabling advanced task management (cf. Requirement R:Sepm1). The Assignment is used as a coarse-grained top-level task, which is also estimated and scheduled from the business side in a project, exemplified in Figure 2 as "Develop feature X". The Assignment Activity then describes the tasks that are necessary to accomplish the Assignment, e.g., "Design Solution" or "Write Developer Tests" (cf. Figure 2). The most fine-grained level is described by atomic tasks like "Check out" or "Build Code".
Combining the Context Management and the Process Management modules enables the automatic adaptation of running workflows based on the current context. This has been used to automatically build workflows for issues extraneous to SE process models, like bug fixing or refactoring as described in [22].
D. Quality Opportunity Detection
To enable the automated detection of quality opportunities, an awareness of the activities that have been planned and scheduled becomes necessary. These are captured by the Assignment, which has certain properties to capture estimated durations. These assignments can be created, estimated, and scheduled in CoSEEEK or imported from other tools. This is illustrated by Figure 7.
Figure 7. Quality Opportunity Detection.
The figure shows a simple example schedule containing the Assignments ‘As1’ – ‘As4’ that are estimated to take three days each. The scheduled Assignments are then taken for execution. The figure illustrates the connection of the Assignment ‘As1’ to four Assignment Activities for execution, which are ‘Aa1’ – ‘Aa4’. Optionally, the schedule can be imported from an external tool. That way, the activities can be estimated and scheduled from the business side, e.g., utilizing a process management tool like microTOOL in-Step [32], and then be automatically used for execution in CoSEEEK.
In our approach, two triggers for a quality opportunity are implemented. The first one is early assignment
completion. If a user finishes an assignment earlier than necessary, a quality measure can be assigned to him without delaying forthcoming activities. The second trigger is the quality overhead factor. It enables the a-priori specification of a certain percentage of the project workload that should be reserved for quality activities. If the user has not yet reached that amount during process execution, a quality measure may be applied. This can be combined with a quality function indicating how much time for quality should be spent in which project phase. Since it has been shown that it can be beneficial to adjust the work allocation for quality based on the stage of a project [12][17], this can improve both the effectiveness and efficiency of the quality efforts taken.
Example 3 (Quality Opportunity Detection): To
illustrate how automated quality opportunity detection could work, Figure 8 shows a simple schedule of the Company. This example, which demonstrates early assignment completion, assumes that the Company has already adapted the planning to create more fine-grained assignments not taking weeks but days. The schedule comprises four users having five assignments each. Each of these assignments, in turn, is estimated to take three days. Every user in this example finishes early on one Assignment, triggering the creation of a Q-Slot filling the hole in the schedule.
Figure 8. Schedule with Q-Slots.
The concrete detection of the quality opportunities is done each time an assignment completes. This can be detected automatically by connecting the Assignments to the users’ Atomic Tasks (cf. Section III.C). Atomic Tasks, in turn, are connected to the development environment via the sensor infrastructure provided by CoSEEEK, generating an awareness of their status. When all Atomic Tasks of an
Assignment Activity are completed, the Assignment Activity
completes as well. The same applies to the Assignments in relation to the Assignment Activities. This process is further described in [25].
E. Problem Detection
Problem detection makes use of the environmental awareness of CoSEEEK to identify potential problems, e.g., in the source code. In this context, external data from tools needs to be integrated. This information is utilized for calculating various metrics that can be customized to measure the quality state of the SE project. Metrics directly indicating problems in the source code are obtained from static code analysis tools like PMD [33] and FindBugs [34], while certain testing problems can be detected with test coverage tools [35] such as Cobertura [36] or EMMA [37].
However, not only code-related product-level problems threaten quality, but process-related factors should also be assessed to ensure quality. These assessments include functional testing, profiling, and load testing. Since CoSEEEK is aware of the execution of respective activities, it can ascertain their absence. Thus, process metrics can also include these facts. Facts available to CoSEEEK can be incorporated in metrics, which enables quality awareness through the presence of measurable, quantifiable information. To reduce the associated configuration effort, a set of pre-configured default metrics will be included with the system.
After detecting any problem, measures (actions) can be used to counter them. The Rules Processing module is utilized for triggering the automatic proposal of a measure when the threshold for a particular metric has been violated. Metric or violation reports are received and analyzed, and a list of the violated metrics including assigned quality measures is created by the module.
Example 4 (Source Code Monitoring): Company policy
includes a nightly built process on a build server that invokes static code analysis tools to enable continuous measurement. Thus, a deterioration of the source code quality can be detected by metrics such as its cyclomatic complexity. If complexity exceeds a threshold, the code becomes difficult to maintain and test, and there is a higher probability of introducing defects.
F. Measure proposal
At this point in the procedure, problems as well as Q-Slots have been detected and an initial assignment of quality measures to metric violations has been done. The generation of a Q-Slot then triggers a measure selection and proposal process. The latter is coordinated by the Context Management module. First, the Context Management
module triggers the AGQM module to prioritize the measures strategically in alignment to the quality goals of the SE project. Thereafter, the measures are tailored to the current situation.
The process of prioritizing measures is very dynamic due to different goals, presence of various metrics and violations and different project situations. Therefore, the AGQM
module features a multi agent system (MAS) to prioritize measures in alignment to the project goals to be able to accommodate these various factors. The process is based on an extension to the GQM technique [30]. GQM consists of a hierarchical structure that starts with the definition of certain project goals. During configuration, for each goal various questions are defined. These answers should provide indicators for the level of goal fulfillment. Each question can be associated with certain metrics, establishing a connection from the abstract project goals to concrete facts in the project. The following example shows the application of the GQM technique.
Example 5 (GQM Plan): As part of a GQM plan, a goal
‘Maintainability’ could be defined relating to the maintainability of the produced source code. For this goal, one question could be ‘How understandable is the code?’ For this question, in turn, different metrics could apply. One example is the metric ‘Comment Ratio’.
1) GQM Extensions
This subsection shows the basic concept on which the agents rely. Two main requirements have to be satisfied to facilitate automatic support for GQM execution. First, a GQM plan must exist that defines the relations between goals, questions, and metrics. Second, the metrics have to be integrated in the system, enabling the automatic extraction of corresponding values and thus the automatic receipt of possible deviation information.
Some extensions to the GQM technique became necessary to support automation. Different abstractions of key performance indicators (KPIs) were introduced to enable the automatic calculation of goal deviations. Furthermore, metrics are encapsulated in KPIs to enable consolidation and simplified deviation calculation. Since multiple metrics may be utilized for a single question in GQM, a QKPI (Question KPI) was created for consolidation of the metric values at the question level. Similarly, multiple questions may apply to a single goal, thus a GKPI (Goal KPI) is used for goal deviation calculations. For each of the KPIs, formulas specify how metrics are combined. To support automated multiple goal attainment, each defined goal was assigned one agent responsible for monitoring and fulfillment of that goal.
The calculation of the different KPIs is conducted by the Context Management module as part of the quality trend
analysis described in Section I. Figure 9 shows the relation between the different conceptual elements.
Figure 9. Extended GQM Structure
To prescribe appropriate countermeasures for (potential) quality deterioration, measures were categorized as follows:
reactive (or analytical) measures, which are directly associated with concrete metrics or violations, and proactive (or preventative) measures, which hereby are categorized as supporting certain quality goals at an abstract level and may not be readily associated with a concrete problem. Proactive measures are assigned to GKPIs and can be triggered either when a GKPI deviation occurs (a supportive role) or in the absence of reactive measures. This differentiation is pragmatic since reactive measures can be based on concrete existing problems and can thus be more fine-grained, whereas proactive measures support a goal in general.
2) AGQM Process
At the beginning of a project or a phase or iteration, a quality manager assigns points to each goal (implying its importance) and chooses a bidding strategy for the agent managing that goal. These points are used by agents for negotiating proposed measures. The AGQM process invokes a proactive as well as reactive selection mechanism that results in a measure proposal.
Quality goals can be conflicting, and determining the appropriate balance is project-specific. Thus, a competitive bidding process among agents is chosen for enabling proactive measures, whereas a cooperative voting process is applied for enabling reactive measures. The competitive bidding allows agents with greater importance to definitively have opportunities to support their goal with measures, in contrast to voting where agent majorities might win. That way, a group of lower-priority goal agents does not hinder a higher priority goal from ever asserting influence. The bidding strategies enable agents to win opportunities earlier or later in an iteration cycle.
The reactive voting process is cooperative since a potentially large number of concrete reactive measures based on metric violations become possible for a limited number of quality opportunity slots (Q-slots), and those measures that will have the greatest overall quality impact across all goals are favored. The agents cooperatively vote on the measures list received from the Rule Processing module. Via the structure shown in Figure 9, each agent determines for each measure whether a measure belongs to a metric being related to the agent’s goal. The points of an agent are then
distributed (currently uniformly) across all measures associated to its goal. A prioritized list of reactive measures is output, while the ultimate choice will be applied by
Context Management based on the situation.
The proactive section of the AGQM module utilizes metrics for calculating the different KPIs, QKPIs, and GKPIs. If there are any deviations at the goal level of an agent (GKPI), it may participate in the bidding session (this favors those goals known to be at risk). Each agent bids and the highest bid wins, elevating its proactive measure set to a proposal. In this process, not just the points differentiate between the goals, but also the strategy chosen by the agents. The strategies influence how an agent increases or decreases its bids after winning or losing for the next bidding process. Choosing a defensive strategy for an agent will increase the likelihood that a proposal of its associated measures will occur in later phases of the iteration. This behavior occurs because in early sessions the agents with more aggressive strategies will place much higher bids. The defensive agent can then place winning bids later when the aggressive agents run out of points.
To define an appropriate proportion between proactive and reactive measures, a proactive-to-reactive ratio can be defined. This determines how often reactive vs. proactive measure sets are provided by the AGQM module. Section V will evaluate a concrete scenario utilizing this approach. If no metrics and thus no reactive measures are yet available, then no question or goal deviation is detectable since there is no basis for their calculation. In this case, all agents participate in proactive bidding so that any Q-Slots can be used for proactive measures.
G. Measure Tailoring
The AGQM module has created a list of prioritized measures according to project goals. However, the final selected measure should depend on environmental factors for the most effective and efficient measure application. These include properties of the measure itself, properties of the applying person, and properties of the current situation.
The properties of the measure are defined in the Context Management module and include, for example, the type of the measure or the applicable number of users involved (e.g., a code review involves multiple persons). One property of the person that can be of interest is the skill level. The properties of the current situation are modeled based on the concepts of the Q-Slot and the Extension Point. The
Extension Point, as part of the semantic enhancements to the process, is a pre-specified point in the process where the integration of a quality measure is feasible, as illustrated in Figure 4. That involves an abstraction level and applicable measure type since, for example, at the end of a project phase other measures might be applicable compared to a time point after directly implementing new functionality. The
Q-Slot captures a time category indicating how much time is left for a quality measure. Via these properties, a measure fitting to the current situation can be chosen. This process is further explained in [25].
H. Measure Application
To enable a high degree of automated guidance, the user is not only informed about the measure to be applied, but the measure is also directly integrated into the users’ workflow (not necessarily visible to the user, but tracked by the system). Both semantic enhancements to process management and the capabilities of the adaptive process management system, which enables the dynamic change of running workflow instances, are used. Details can be found in [25].
Example 6 (Measure Selection): To enable automated
support for quality measures, the Company introduced the facilities for automated problem and quality opportunity detection. A GQM plan was created with maintainability and reliability as well as the creation of new functionality as goals. If developers now finish early on Assignments, the system can automatically assign them quality measures that fit the project goals and are appropriate to the personal situation. As example for this, consider refactoring of complex code. This measure was triggered as problems in the source code were detected, for example by applying the cyclomatic complexity metric. The measure was prioritized as high since it was judged as important and applicable to both the maintainability and reliability goals of the project. Finally, the system can choose the matching person for the measure based on properties like the skills of the person, their familiarity with that code section, or the amount of time they can spend in accomplishing a measure vs. the expected time needed for the measure.
I. Quality Trend Analysis
The continuous monitoring of the quality of the source code is essential to be able to detect any impact of applied quality measures. Therefore, the list of quality measures from the Rule Processing module is utilized by the Context Management module. The list not only contains proposed measures, but also the metric belonging to each measure and the value of the metric. To enable automated evaluation of quality trends in conjunction with the GQM technique, different levels of key performance indicators (KPIs) were introduced as depicted in Figure 9.
KPIs are composite metrics unifying the values of other metrics or KPIs to enhance their expressiveness and significance. Each KPI is based on a formula that prescribes how the values of the encapsulated metrics are used to compute the KPI value. KPIs are utilized not only for quality trend analysis on different levels of abstraction, but also for automated goal deviation monitoring with respect to the GQM technique. Therefore, three levels of KPIs were introduced: on the most concrete level, the KPI unifies one or more metrics for clarity since different metrics may be utilized by the system. The QKPI represents a Question of the GQM technique as a value to facilitate automated deviation calculation, which is automatically computed from attributed KPIs and base metrics. The same applies for the GKPI, which unifies the values of the questions belonging to one project goal.
Compared to our initial approach described in [1] and [25], the calculation of the KPIs has been refined and moved
to the Context Management module. Therefore, the KPI structure and the various calculated KPI values are stored in the ontology for better information processing and access. The values can then be incorporated in reasoning procedures and the data can be easily provided to other external applications.
The calculations are now done in a uniform way for all KPIs, applying a weighted average of all values a KPI
aggregates as depicted in Formula (1), where Mi are the
concrete values that are aggregated and Wi are the attributed
weights of the n metrics or KPIs being aggregated. All received metric values are normalized to a range from 0 to 1.
∑
∑
= = = = = i n i i n i i i i W M W KPI 1 1 (1) J. Measure AssessmentRegarding different companies with different people, tools, and processes, applied measures may show different degrees of effectiveness. To reflect that and to improve future measure proposals, a so-called measure utility is introduced to indicate the usefulness of the applied measure. That property is neutrally initialized and updated after each application of the measure. The delta of the KPI related to the measure right after its application is compared to the value prior. Since some measures may not have an immediate effect, multiple future deltas can be taken into account. This process is further described in [25].
Example 7 (Measure Assessment): The special
refactoring proposed in Example 6 can now be automatically assessed for the Company since it has applied continuous quality measurement. If the refactoring is successful and the complexity of the code is reduced, this is indicated by a subsequent measurement showing a lower value for the cyclomatic complexity metric. This value will then also affect the value of a KPI related to the maintainability goal defined by the Company. The KPI value, in turn, will affect the utility value of the proposed refactoring measure, which will, if successfully applied, have a higher probability of selection by Context Management in the future.
IV. REALIZATION
This section provides implementation details for the components described in Section III and reflects their current implementation status.
A. Architecture
The technical architecture is depicted in Figure 10, whereby the modules are deployed as web services. To support loose coupling of the deployed services in CoSEEEK, event-driven computing and space-based computing are leveraged for service interaction [21]. The communication with the tuple space is technically realized using the web service framework Apache CXF.
For SE Tools and Artifacts, the actual instances are dependent on the SE environment and the current
configuration. In the context of this paper, SE Tools includes static analysis tools like PMD, version control tools like Subversion, and IDEs (Integrated Development Environments) like Eclipse. Other relevant tools are, for example, external project management tools from which processes can be imported, like microTOOL inStep [32].
The primary Artifacts relevant to the scenario presented in this paper are source or test code files that are processed using these tools.
The Event Extraction module utilizes the Hackystat framework [38]. This framework provides a rich set of sensors that can be integrated into various SE tools. The sensors enable the Event Extraction module to automatically generate events in different situations, as, e.g., checking in a source code file in Subversion or switching to the debug perspective in Eclipse.
Most of the extracted events are rather atomic and thus combined by the Event Processing module to provide more semantic value. This is done utilizing Esper [39] for CEP. Esper provides a facility to define patterns that govern how certain events are combined to derive other higher-level events, which are then again written to the Data Storage
module as all other events.
The Data Storage module, in turn, is realized via an implementation of the tuple space paradigm [40] on top of the XML database eXist [41] for shared XML data, whereas the Hackystat SensorBase is used for high volume event data. The specific CoSEEEK tuple space implementation that uses eXist consists of multiple so-called collections that structure the stored information. Examples include 'Context Management' as well as 'Process Management'. Each CoSEEEK module can write tuple events in these collections or subscribe to be automatically informed about new events in a certain collection.
The Rules Processing module automatically processes static rules to assign certain quality measures to certain violated metrics utilizing JBoss Drools [42].
The AGQM module, which is in charge of strategic quality measure prioritization, employs a multi-agent system (MAS) with different behavior agents. It is implemented utilizing the FIPA- compliant [43] Jade framework [44].
The Context Management module employs semantic technology to enable high-level utilization of all project knowledge. Technology advantages include enhanced interoperability between different applications, extending reuse possibilities, and the option for advanced content consistency checking [45]. It also provides a vocabulary for the modeled entities including taxonomies and logical statements about the entities. Ontologies also provide the capability of reasoning about the contained data and inferring new facts. As an ontology language, OWL-DL (Web Ontology Language Description Logic) [46] is used due to its proliferation and standardization. For simple RDF [47] based queries to the ontology, SPARQL [48] is used. Operations that are more complex are executed using the reasoner Pellet [49]. Programmatic access via DAO objects to the ontology is provided by the Jena framework [50]. Thus, different semantic concepts can be created and manipulated as needed.
Figure 10. CoSEEEK Technical Architecture
The Process Management module builds upon the AristaFlow BPM Suite [51][52]. AristaFlow provides process management technology that is notable with respect to the flexible support of adaptive and dynamic workflows. New workflow templates can be composed out of existing application services in a plug-&-play like fashion, and then serve as schema for the robust and flexible execution of related workflow instances. In particular, during run-time, selected workflow instances can be dynamically and individually adapted in a correct and secure way; e.g., to deal with exceptional situations or evolving business needs [53]. Examples of workflow instance changes supported by AristaFlow include the dynamic insertion, deletion, or movement of single workflow activities or entire workflow fragments respectively (for a discussion of the adaptation patterns supported by AristaFlow, see [54]). For integrating these change functions and other AristaFlow services (e.g., for managing user work lists or for defining workflow templates) with domain- or application-specific process-aware information systems as in our case, the AristaFlow Open Application Program Interface (Open API) can be utilized [55][56]. For example, for dynamically inserting activities at the workflow instance level, the application developer can make use of the following system functions provided by the AristaFlow Open API:
• Querying the activity repository for available activity templates,
• Marking those activities of the workflow instance after which the selected activity shall be inserted (i.e., after completing these activities the newly added one shall be enabled),
• Retrieving the set of activities selectable as “end” activities for this insertion,
• Marking the activity (or set of activities) which shall serve as end activity (activities),
• Performing (tentatively) the insertion based on this information,
• Checking the AristaFlow report on detected errors (e.g., missing values for input parameters), and • Making the instance change persistent.
Note that dynamic workflow instance changes can be conducted at a high level of abstraction. In particular, all complexity relating to dynamic workflow instance changes (e.g., correct transformations of the workflow schema, correct mapping of activity parameters, state adaptations) are hidden to a large degree from end users and application developers respectively [57]. Furthermore, AristaFlow provides techniques for learning from past experiences and workflow instance adaptations, respectively, and for evolving workflow schemes accordingly [58][59][60].
B. Context-aware Business Process Management
As mentioned in Section III, CPM (Context-aware Process Management) is enabled by correspondingly modeling the workflows in the ontology. Figure 11 illustrates this with the 'Develop Solution Increment' workflow of the OpenUP process [61].
In traditional process management, as mentioned in Requirement R:Sepm2, some aspects of task management have not been sufficiently covered. On the one hand, coarse-grained user assignments that have been planned for the current iteration or phase are not explicitly included since they are too abstract. In CoSEEEK, this is done explicitly in the Context Management module, as illustrated in Figure 11, by the Assignment 'Develop Feature X'. The latter is connected to the Work Unit Container that, in turn, contains all Work Units representing the activities of the workflow. If human tasks shall be executed via those activities, they are implicit parts of these activities.
In CPM, modeling it is done more explicitly. Work Units representing activities are only used for workflow governance. If they shall imply human activities, they have to be connected to Assignment Activities. The latter are also connected to the Assignment, making the connection of the abstract assignment to the concretely executed activities more explicit. However, activities like 'Implement Solution', in turn, consist of a number of smaller tasks. These tasks are also explicitly modeled in CPM. Figure 11 shows the Atomic Tasks related to the 'Implement Solution' Assignment Activity. These tasks can be automatically detected by the sensors of CoSEEEK’s Event Extraction module. Thus, it is possible that the system is automatically aware of the completion of an activity through the detected completion of all related tasks and thus can automatically finish that activity and propose the next one. This relieves the user from the burden of always explicitly informing the system about activity completion. The same applies to the Assignment, which can be automatically finished by the completion of all related Assignment Activities.
Figure 11. Concepts in Process Management and in the Ontology. The enrichment of process management concepts via the
ontology further enables the aforementioned extended vertical relations between workflows and the clear separation between horizontal and vertical process management (cf. Section III.C). The separation into two areas governed by two different modules was chosen despite the high coordination effort it imposes. The main reasons for this are as follows: mirroring process management components in the ontology not only enables extended vertical process management, but also allows for a tighter integration of the processes in the projects using different task levels for humans and CoSEEEK’s environmental awareness capabilities. Since the decision on whether or not a Work Unit and the respective node can be completed is done in the
Context Management module, the vertical dependencies are integrated into that procedure as well. Thus, multiple dependencies are all managed at one point, fostering contextual integration of process management and dependency extensibility. A Work Unit cannot complete, for instance, if related user activities are not completed or if the
Work Unit depends on activities by other users or teams. An example of new dependencies that can be easily integrated is that an artifact has to be in a certain state or that an external tool has signaled a certain event. The horizontal governing of a process structure stays with process management because this is a non-trivial task and mature process management systems such as AristaFlow (cf. Section IV.A) support many correctness checks and guarantees on process execution. The extensions to vertical process management made by CPM are detailed in the following. There exist three possible
connections, all of which can occur multiple times and can be mixed:
- Depends-on-Work Unit Container: This is the classical connection between an activity and a contained sub-workflow. When the Work Unit is activated, the Sub Work Unit Container is started and the Work Unit must not complete until the Sub Work Unit Container is completed. This connection is illustrated in Figure 6 by the Work Unit ‘B4’ that depends on the Work Unit Container containing the Work Units ‘C1’ – ‘C4’. - Depends-on-Work Unit: In this connection, the
completion of the current Work Unit does not depend on a Work Unit Container, but on the completion of another Work Unit. When the depending Work Unit is activated and the Work Unit Container containing the
Work Unit on which the current Work Unit depends has not been running yet, it is started. This connection is illustrated by the Work Units ‘A3’ and ‘B4’ in Figure 6. - Initiates-Work Unit Container: This connection is
asynchronous. The Work Unit does not depend on anything, but when it becomes activated, the connected
Work Unit Container is started.
C. Procedure
This section gives a short outline about the temporal coordination of different modules. The whole procedure can be decomposed into three processes partly dependent on each other:
- When a report from an analysis tool is received, the tool-specific format is first transformed into a
unified one. Thereafter, the report is processed by the Rule Processing module with triggered measures output to Data Storage whereby any subscribers are notified. They retrieve and use the data, in this case the reactive section of the AGQM
module and the KPI calculation of the Context Management module.
- When a user finishes an activity, the Q-Slot detection is started within the Context Management
module. If a Q-Slot is available, the AGQM module is triggered by the Context Management module to generate an ordered list of proposed measures. This list is used by the tailoring process in Context Management to select a measure that is then integrated into a workflow by the Process Management module.
- At certain configured time points, the Context Management module is triggered to do an assessment of the applied measures. This relies on the applied measures and the calculated KPIs.
D. Problem Detection
Problem detection relies on the receipt of information about CoSEEEK’s environment. This is indicated by events in the CoSEEEK infrastructure. For reports of external tools, these events include the location of the reports. Other facts like the execution of load or functional tests may only be indicated by events and are continuously monitored. When reports are received, the Rule Processing module is triggered. To be able to automatically evaluate metrics and to assign appropriate measures if thresholds are exceeded, the module must be aware of the metrics, the measures, the thresholds, and the tool used to measure the metrics. Thus, we developed a GUI to more easily define the involved items as depicted in Figure 12.
Figure 12. Rules GUI.
The rules produced by this GUI have the structure defined in Listing 1 and allow for the definition of rule priorities. The latter are used if, for example, two rules with different thresholds have been defined for the same metric and only one should be executed if both are triggered. The rules are then exported, transformed into the DRL format utilized by JBoss Drools, and loaded by the Rules Processing
service. Any new reports then utilize the new rule set.
Listing 1: Rule example <rule ID="12" Tool="PMD" Metric="MET:UnnecessaryConstructor" Trigger=">=1" Measure="M:R:PeerReview" Prioritized="2" />
Rule processing produces unified XML reports containing all metrics whose thresholds have been violated and their associated triggered quality measures.
E. Measure Proposal
The output of a new unified report triggers the Context Management module to start the measure selection. For the prioritization of the measures, the AGQM module is triggered. This subsection gives some details about the agents utilized in the AGQM module.
The agent structure is defined as depicted in Figure 13. The AGQM agent is responsible for managing the agent module. It instantiates the other agents and determines whether a reactive or proactive measure will be proposed. For each defined goal, one goal agent is instantiated. In the proactive section, the goal agents communicate with the so-called session agent to realize the bidding process. The session agent takes the role of the “buyer” and thus selects the proactive measure from the goal agent with the highest bid. Each goal agent places bids according to its strategy. For the initial implementation, basic strategies were used. The three strategies ‘offensive’, ‘balanced’, and ‘defensive’ influence the starting bid of the agents as well as win-or-lose adaptation based on the last session. The strategy pattern allows these algorithms to vary. If insufficient points are left for the intended bid, the agent bids all points he has left. If an agent has no points left, it cannot place bids anymore until all agents have no points left, whereupon all points are reset to their initial value. Each agent has a list of proactive measures it could offer. Goals that are known to be at risk due to GKPI deviation are elevated to participation status in the bidding. If no report containing GKPI violations is received, all agents participate.
Figure 13. Agent Structure.
The reactive section is realized via the vote agent. Each time a report is received, the vote agent creates a weighted list of reactive measures using the report. To elicit the weight of each measure, the vote agent communicates with the goal agents. For each measure, a goal agent evaluates whether that measure is associated to its goal via the aforementioned
connection of measures, metrics, KPIs, and goals. In each voting process, a goal agent distributes all of its assigned points (initially allocated at the beginning of the iteration) uniformly across all measures in the current report that are associated to its goal. If multiple agents vote on one measure, the points are aggregated. If no report has been received yet, the voting process cannot be conducted. In that case, a proactive session is substituted.
That way the AGQM module creates a new ordered list of measures that mirror the predefined importance of the project’s quality goals.
F. Measure Application
This part of the process was discussed in our initial approach [25]. However, due to technical issues, it has been extended and refined and this subsection presents how the integration of new quality measure activities into the user’s workflow is accomplished. Therefore, new items have to be inserted both on the Context Management side and the
Process Management side. This is done at first in the Context Management module. A quality measure is inserted as a new
Assignment comprising certain AssignmentActivities and a separate WorkUnitContainer with WorkUnits and potential new ExtensionPoints. These are created from pre-specified template concepts that are connected to the
MeasureTemplate (that is mentioned in Figure 17). To be able to insert the quality measure at the specified point, a new WorkUnit is created and inserted there, which is then connected to the newly created WorkUnitContainer
belonging to the quality measure. This is illustrated in Figure 14.
Figure 14. Measure Integration.
However, the insertion itself has to be also done within process management and therefore takes place later. In order to adapt a running workflow instance in AristaFlow, it has to be suspended from execution to apply the adaptations. This cannot be done if an activity in the instance is still active. However, at the time the quality measure integration is triggered, the activity that caused the Q-Slot generation is still active. Therefore, suspension is delayed until the activity is completed. This procedure is shown in Figure 15.
After the new individuals (WorkUnits, etc.) in the ontology have been created, a so-called DeferredAction is
created and assigned to the ExtensionPoint where the measure should be integrated. That action will be automatically executed when the WorkUnit related to the
ExtensionPoint is finished and will integrate the Activity
containing the measure (named ‘Q’ in Figure 14) in the workflow instance. After that, a ‘soft suspend’ event is sent to Process Management, causing AristaFlow to do a soft suspend on the respective workflow instance. Thus, the instance will be automatically suspended right after the currently running activity is finished. This happens when the related Work Unit finishes via a ‘signal Activity’ event. This, in turn, causes the final integration of the quality measure activity in Process Management and is mirrored in Context Management.
Figure 15. Measure Integration Procedure.
The order of the activities in the integration procedure was chosen in a way that the current activity is still running while the measure integration process starts. This was done to allow the insertion of a quality measure directly after every activity even if this is the activity the user currently processes that caused the creation of a Q-Slot. The soft suspend immediately suspends the workflow instance after activity completion and therefore no other activity is started. Then, the quality measure activity can be integrated and executed as the next activity if appropriate.
G. Quality Trend Analysis
The quality trend analysis is conducted in the Context Management module and the values are stored in the ontology. The concepts are illustrated in Figure 16.
Both Metric and KPI are united under the concept of the
QualityIndicator. All concepts are separated into a template for the definition and a form containing a concrete value. When a ViolationList containing multiple Metrics is received, it is determined which KPI can be calculated via the KPITemplate and the MetricTemplate. For the computed values, new KPIs are then created.
To be able to do a uniform calculation, all received metric values are normalized to values between 0 and 1 where 1 is the best possible value and 0 is the worst possible one. Therefore, as part of the MetricTemplate, there is a defined maximum saved. The actual value is divided through this maximum to derive a value between 0 and 1. It also
defines a limit for the value, e.g., if a maximum of 15 has been defined as maximum for cyclomatic complexity, this would be the worst possible value. If the actual values had exceeded this limit, then 15 would be taken instead. There is also a property called negative, which indicates whether high values are negative (bad) or positive (good) indicators.
Figure 16. Quality Trend Analysis.
If a metric value is not available, the calculation will be done without that value. For some metrics, the absence of a value is also a negative indicator and thus a standard value can be defined in the MetricTemplate. If, for example, a metric had indicated the degree of functional testing compliance (a measure for the outcome of functional testing), its absence would indicate that no functional testing has been done yet. Since that fact should not be overlooked, a standard value can be defined.
It is also possible to integrate values from external tools as KPIs. If this is the case, a property 'external' can be used to indicate this. The KPI calculation is a weighted average and therefore each KPITemplate stores the weight used for that KPI.
H. Measure Assessment
In this part of the process, the calculated values of the KPIs are utilized for recalculating the measure utility factor. This is done using the changes (deltas) of the KPI values. For now, up to ten such deltas starting from the time of the measure application can be used. The concepts in the ontology realizing this are depicted in Figure 17.
Figure 17. Measure Assessment.
More details on this calculation are provided in [25]. Compared to our initial approach, the ontology structure has
been refined featuring the separation into template concepts and concrete ones for all involved concepts. Thus, they conform to the overall structure, implying a strict separation of the definition of certain items and their concrete values. That way, additional plausibility checks are also possible like the check whether a measure is permitted for a certain metric violation.
I. Modeling Effort
The presented approach implies modeling workflows and a myriad of extensions to them in the ontology. This leads to a relatively high modeling effort. That effort can nevertheless be limited: When the modeling is done utilizing the SE workflow language we developed in [24], both the concepts for the Process Management and the Context Management modules are automatically generated. If workflows are already in place in a workflow management system, the basic concepts in the ontology (Work Units and
Work Unit Container) can be automatically generated and then be annotated manually. This could also limit the effort required for migrating to CoSEEEK in a company. If a supported workflow management system is in place there, only the annotations (e.g., Extension Points) have to be added manually. CoSEEEK will also include predefined metric sets and associated measures, standard SE processes, and GQM plans to facilitate the introduction of the system. That way small and medium sized companies could easily benefit from the higher level of automation CoSEEEK provides.
V. EVALUATION
A scenario was constructed and technical measurements taken to evaluate the overall feasibility of the approach.
A. Scenario
Due to the large number of configuration factors involved and the breadth and depth of the approach we developed, a controlled scenario-based evaluation that combines real results with synthetic facts was chosen for initial feasibility testing. As input for code analysis, the org.eclipse.osee.framework.database package of the open source Eclipse Open System Engineering Environment was used.
1) Process
As a software development process, OpenUP [61] was chosen, a simplified free derivative of the Unified Process [62]. This process constitutes an iterative process featuring four project phases. In the Inception phase the scope of the project is defined, the use cases are outlined, risks are identified, and candidate architectures are selected. The
Elaboration phase serves for capturing a healthy majority of system requirements and for addressing known risk factors. In addition, the system architecture is established and validated. In the Construction phase the system features are built based on the selected architecture. In the Transition phase, the system is deployed to the users. Each phase contains a number of iterations to complete its goals. Figure 18 shows how the OpenUP process can be used in the given scenario.
