Software release planning plays a crucial role that affects the success of software engineering project management (SEPM). Release planning (RP) determines ...
Page 1 of 10
The Science and Practice of Software Release Planning Günther Ruhe Moshood Omolade Saliu University of Calgary Laboratory for Software Engineering Decision Support
Software release planning plays a crucial role that affects the success of software engineering project management (SEPM). Release planning (RP) determines which customer gets which features at which moment. In the 2002 Standish Group report, it was observed that mismatching customer satisfaction with the functionality of delivered software is still one of the main reasons that many software projects fail to achieve their stated objectives. Despite the importance of RP, our study reveals that current industry practices are mainly based on informal procedures. Most of the existing RP approaches are not based on comprehensive involvement of stakeholders, and do not give enough attention to resources and other constraints influencing RP decisions. This article provides guidelines for RP and lessons learned in performing RP. We give overview of existing RP techniques and describe a case study using an intelligent decision support tool called ReleasePlannerTM. We present industry experience to describe the added value in terms of the quality of plans, the ability to better react to changing customer demands, the ease of performing planning and replanning more efficiently, and the ability to make proposed decisions more transparent. Planning Releases for Incremental Software Development Incremental development allows customers to receive part of a system early. Each release is a collection of features that forms a complete system that will be of value to the customer. Incremental development has many advantages over the traditional waterfall approach. First, prioritization of features ensures that the most important features are delivered first. This implies that benefits of the new system are realized earlier. Consequently, less important features are left until later and so, if the time or budget is not sufficient, the least important features are the ones most likely to be omitted. Second, customers receive an early version of the system and so are more likely to support the system and to provide feedback on it. Third, the schedule and cost for each delivery stage are easier to estimate due to smaller system size. This facilitates
project management and control. Fourth, user feedback can be obtained at each stage and plans can be adjusted accordingly. Fifth, an incremental approach is sensitive to changes or additions to features. Current Challenges in Release Planning Software companies are faced with endless product planning challenges: conflicting requirements, complex platform/product and roadmap dependencies, time-tomarket pressures, resource bottlenecks and geographically dispersed stakeholders and project teams. RP is an important and integral part of any type of incremental product development. The complexity of RP is partly due to the incompleteness and uncertainty of the information that characterizes RP problems. The overall goal of RP is to assign features to releases in a way that maximizes some stakeholder related objective functions [10], while balancing a shortage of resources Experience in RP and requirements prioritization is seldom reported. A few exceptions are [1], [5], [6], [15], [16]. Main weaknesses observed are: •
• •
• •
•
RP is typically done ad hoc, not based on sound data, models, experience and methodology. This is even the case when planning for several hundreds of features. As a consequence, the created plans do not create the maximum value achievable from the resulting products. The process of planning is seldom established and not repeatable. It is typically intended to plan just for the next release. The plans are made without careful consideration of the involved resources. This results in frequent extension of budgets, due dates and quality target limits. Stakeholder involvement is insufficient. As a consequence, the resulting plans do not address stakeholder concerns appropriately. RP consumes a significant amount of time for the product or project manager. As RP is based on meetings, it consumes time for involved stakeholders as well. There is no capability and support for playing what-if scenarios to better understand the
Page 2 of 10
limitations and bottlenecks of the current planning problem and to manipulate the different degrees of importance of the main customers and users when planning product features. Relationship of RP to Software Engineering Project Management Software Engineering Project Management (SEPM) supports the performance of scheduled processes during the whole project, monitors progress, controls estimates about effort and time, and initiates re-planning. Poor RP decisions will likely lead to project failure even with good project management in place. RP feeds information into SEPM. Without good RP decisions, critical features might get jammed into the release late in the cycle [16]. This situation could result in unsatisfied customers, time and budget overruns, and a loss in market share. The project management process area of the CMMI [7] covers activities related to planning, monitoring, and controlling projects. According to the CMMI, the purpose of project planning is to establish and maintain plans that define project activities. These include developing the project plan, involving stakeholders appropriately, obtaining commitment to the plan, and maintaining the plan. One major issue addressed at Maturity Level 2 of the CMMI is the identification of “what” is to be done in project planning, but the RP process is a more detailed solution of “how” to do certain aspects of project planning. A generic RP process model would help organizations to share best practices and to learn from established activities. On-time delivery or reduced time-to-market of a product is a common business objective. The project planning, project monitoring and control process areas of the CMMI aim at achieving this objective amongst other objectives; but realistic project planning cannot be done without an established RP process. The Release Planning Process The quality of a release plan is governed by the quality of the process used to develop the plan. There is a need for the process model to act as a guide to generating qualitative and realistic release plans. An explicit process model offers an opportunity to attach
quantitative goals to each instance of the planning process. In our attempt to build an acceptable process model, it is required that we consider different RP scenarios in software development. Figure 1 shows a generic process model describing main RP activities and their related inputs and outputs. Therein, three roles that contribute to the process and products of RP are identified – project managers, stakeholders and support environment. Activities occur directly under the roles that are actively involved. For example, project managers and stakeholders’ roles are involved in feature elicitation, while a support environment maintains the group of features elicited. The support environment may be a simple spreadsheet or it may be an intelligent tool support, depending on the sophistication of the RP methodology. Major activities of the process model are described by rounded-rectangles, while intermediate results of each activity are shown in ovals. Following is a detailed discussion of the key tasks of the process model. Feature elicitation: Elicitation of features is a prerequisite for their subsequent planning. A variety of techniques are known to determine what the users and customers really want. To collect meaningful features, the right stakeholders must be identified. It is a complex problem itself that is not studied in this paper. For an overview we refer to [7]. Problem specification: This step formalizes the objective function that models the underlying problem and identifies all the constraints present in the features. These constraints may be related to interdependencies among the features, or on dependencies of features on the existing system environment when planning an evolving system. Resource estimation: Resource estimation is aimed at determining the likely amount of effort and cost required to implement the features. This task is crucial to the success of the RP process, because it matches the resource requirements of the problem with the available project resources. The resource estimation technique to be used depends on the data available and project type. Briand and Wieczorek [4] provide detailed discussion of resource estimation techniques. The results from this task are (initial) estimates of required effort and cost as well as projected revenue for the implemented features.
Page 3 of 10
Project Manager
Stakeholders
Feature elicitation
Problem specification
Group of features to be planned
Objectives & constraints present
Resource Estimation
Stakeholder voting
Cost, effort, revenue estimates
Stakeholders assign priorities to features
E: Generation of qualified release plan alternatives
Evaluation of plan alternatives
Release plan alternatives
Most attractive/appropriate release plans, explanation and reporting
Scenarios for re-planning
New/evolving features
Shortage of resources
Support Environment
Implementation
Figure 1: The release planning process. Stakeholder voting: Stakeholders are the people who directly or indirectly influence or are influenced by the software project plan. They may include developers, managers, customers, and users. Giving stakeholders the opportunity to vote on features according to their preferences is important because they set the track of the project and decide the evaluation criteria for its success. The result of this activity is a set of priorities assigned to features according stakeholders preferences. Release plan generation: Information derived from the products of all the preceding tasks and other constraints are used in generating sets of release plan alternatives. This could be done using ad hoc procedures or through well-defined models and sophisticated algorithms.
After assignment of features to releases, a procedure is necessary to determine whether any of the alternative solution plans generated meet the expectations of the decision-makers. Evaluation of plan alternatives: A set of generated release plan alternatives is analyzed to determine if any of the plans meet the explicitly/implicitly formulated objectives. Otherwise, different re-planning scenarios are formulated. These could involve redefinition of various parameters influencing release plan generation or enforcing harder constraints by pre-assigning some features. Another set of release plan alternatives resulting from the re-planning scenarios are generated and the analysis repeated. Once a decision is made the
Page 4 of 10
resulting plan and experiences are documented in the context of the problem. Implementation: Once decision is made and a plan is chosen, development of the features selected for the first release commences. During development of the system, shortage of resources could occur because of inaccurate initial estimates; a feedback loop enables more fine-grained estimation using current knowledge about the project to update estimated values. Release Planning Guidelines Benefiting from the extensive experience of one of the authors of this paper with several years of close collaboration with industry software engineering projects planning and management, we have identified key guidelines that will more likely generate feasible and valuable release plans. (1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
Feature elicitation: Features should be described so they are understandable, unambiguously, consistent, completely, and correct. Grouping of features: In a large set of features grouping becomes important. Grouping features also allows you to assign individual access rights to competing stakeholders so you can prioritize their proposed features. Effort estimation: The success of release planning heavily depends on the quality of the data. Best results are achieved by a hybrid approach combining expert judgment with some formal approach. Estimates on effort and resource consumption may have to be updated during the course of implementation. Planning objective: RP technique should have an approximate definition of objectives. The focus could be related to maximizing the value of releases or maximizing the weighted sum of stakeholder satisfactions or a combination of both. Stakeholder involvement: There are different points of view impacting prioritization. These are coming from a business, a customers or an implementation perspective [15]. A balanced set of representatives is core to get the most relevant planning information. Constraints: The most critical resources have to be considered to generate plans that are more likely to be feasible. Risk: Consideration of risk should be part of the planning process. Although hard to quantify, risk consideration helps to generate plans that are more likely to be feasible and operational. Coverage of feature dependencies: Identify singular requirements early. If two requirements
(9)
(10)
(11)
(12)
(13)
(14)
have similar slogans (topics) then they can be considered to be similar [6]. Scope and time-horizon of planning: Planning for only one release (i.e. next one) is not enough; dissatisfactions are highly likely to arise [5]. For fixed release dates scenario, two or more releases should be planned in advance, depending on release intervals. Prioritization of features: A voting scheme is desired to allow all stakeholders to show their preferences on features prioritization. A three, five or nine point ordinal scale scheme is typically best to reflect the degree of knowledge available. Prioritization of stakeholders: This gives the chance to differentiate between the key users, secondary users, and unimportant users. Re-planning: Because of feature volatility and all the inherent uncertainties, re-planning has to be conducted at appropriate time intervals to accommodate changes. Tool support: Tool support is of great value to project managers that need to make release decisions, and becomes even more important as the project encompasses more requirements, stakeholders, and resource types. Synchronization: RP activity cannot be successfully carried out in isolation without synchronizing to other development activities like SEPM.
Release Planning Methodologies Various methodologies aimed at addressing the RP problem have been used in industry and many more approaches have been proposed in academic research. The current state of science and practice based on our categorization include the following: Ad hoc (No-plan) Approach Some organizations do not see RP as a separate activity during the development process. Many release plans focus only on the target release contents [14], rather than on defining incrementally releasable products. Anton [2] reported that a complex project will likely fail without a plan. Ad hoc methods are used to determine solution plans but are far from objective demands. Many organizations have an ad hoc plan that relies solely on the judgment of the project manager. Penny [16] gave a high-level approach to RP for enhancive maintenance. The central principle employed was to estimate the effort for all features and to estimate total effort available, ensuring they are equal within a confidence level as the project implementation
Page 5 of 10
progresses. The approach does not have a prioritization scheme to select features from the pool.
and couple requirements in various releases, while also considering resource allocation
An ad hoc approach may be suitable for a relatively small in-house project involving few tens of features and relaxed constraints.
Optimization-Based Techniques) Considering the complex nature of RP, several studies have modeled the problem of selecting release features as a specialized optimization problem. In formulating an optimization model for RP, Bagnall et al. [3] assign weights to customers based on their importance to the software company. The objective is to find a subset of customers whose features are to be satisfied within the available cost. Ho-Won Jung [11] follows a similar footing with a goal of selecting features that give maximum value for minimum cost within allowable cost limits of a software system.
Planning Game (Extreme Programming) The planning game (PG) refers to the process of planning and deciding what to develop in extreme programming (XP) projects. The goal is to deliver maximum value to the customer in the least time possible. Customers write story cards describing the features they want, while developers assign estimates of time required to develop those features. The customers then choose the most promising story cards for the next release by either setting a release date and adding the cards until the estimated total matches the release date, or selecting the highest value cards first and setting the release date based on the estimates given on the cards. PG has strengths in the simplistic and straightforward approach it adopts, which works well in smaller projects. However, as the size and the complexity of the projects increases, the decisions involved in planning releases become very complex. According to [14], XP (and thus PG) does not provide guidance on some key issues. XP does not: address how a development group should interact with key stakeholders describe how to produce consistent features and priorities that satisfy multiple stakeholders provide a suggested technique to balance conflicting demands of multiple stakeholders provide a technique for managers to assess the value of proposed features. Requirements Prioritization Requirements prioritization is an activity that involves classification of requirements according to their importance. Prioritization methods allow features to be processed uniquely or pair-wise compared to other requirements. An evaluation and comparison of existing prioritization methods is discussed in [13]; in which most of the methods focus on a cost-value [12] approach or ordinary negotiation. A pair-wise comparison, for example, can be difficult when the number of features grow large. Priority decisions become very complicated when stakeholders have different relative importance and different preferences. Priority decision-making is also complicated by the presence of constraints to sequence
These optimization approaches cope better with larger problem sizes, but customers are not given an opportunity to participate in RP decisions. The importance of customers to a company is not the only issue RP should seek to satisfy. Most of the problems discussed for “planning games” above arise equally here. Hybrid Intelligence Approach The hybrid intelligence approach for RP proposed by Ruhe et al. [17] is an extension of the optimizationbased techniques. The belief that computational intelligence cannot replace a human decision maker was the driving force of this approach. A synergy between the two decision strategies was explored. The overall architecture of this approach called EVOLVE* [17] is designed as an iterative and evolutionary procedure mediating between the real world problem of software RP, the available tools of computational intelligence for handling explicit knowledge and crisp data, and the involvement of human intelligence for tackling tacit knowledge and fuzzy data. At all iterations of EVOLVE*, three phases are passed: modeling, exploration, and consolidation. We will later illustrate the approach in a case study example. Incremental Funding Method The incremental funding Method (IFM) introduced by Denne and Cleland-Huang [9] is a data driven and financially-informed approach to software development. IFM differs from other RP techniques by focusing on revenue projections. That is, it concentrates on the rate at which value is returned to the customer. The main idea behind IFM is to prioritize features by their value called minimum marketable features (MMF). These are defined as small self-contained features that can be
Page 6 of 10
delivered quickly and that provide market value to the customer. Once the MMFs have been identified, the costs and projected revenues are analyzed over the number of periods established by the business. The strength of IFM lies in its simplicity and in its financially informed decisions, but it does not provide the level of sophistication in considering most RP constraints. This consideration of constraints forms the focus of the hybrid intelligence approach.
The trial project encompasses 25 features for a telecommunication company. The list of features is given in Table 1. For brevity’s sake, the estimated resource requirements for each resource type needed for implementation also appear in the table. There are different types of resources required to implement the proposed features. These resources are in the form of effort and capital requirements. Each feature has an equally associated risk level. In addition, the available capacity bound for both releases are given for all resource types.
Intelligent Release Planning Decision Support To demonstrate the added value of a systematic and intelligence based release planning approach, we explore a major RP tool and its usage in industry. ReleasePlannerTM (www.releaseplanner.com) is a webbased support tool for assigning features to releases. It implements the hybrid intelligence RP methodology [17]. We describe a case study project taken from the telecommunication domain, and discuss the solution using the generically proposed process model depicted in Figure 1 as a guide.
The planning process is for the next two releases of the company TELECOM’s product development. There are seven stakeholders participating in the evaluation process. They represent different types of customer organizations, and different roles in the development process. Table 2 lists the seven stakeholders with their relative importance. There are two technological constraints • USEast Inc. Feature 1 is coupled with USEast Inc. Feature 2, and • China feature 1 must precede China Feature 2.
Table 1: Features, resource consumption and available resource capacity for the two releases ID
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Feature Name & Group
Group 1: China Telecom 16 sector, 12 carrier BTS for China China Feature 1 China Feature 2 China Feature 3 China Feature 4 China Feature 5 Group 2: General Features Common Feature 01 Common Feature 02 Common Feature 03 Common Feature 04 Group 3: Strategic Features Software Quality Initiative Expand Memory on BTS Controller FCC Out-of-Band Emissions Group 4: India Market Entry India BTS variant India Market Entry Feature 1 India Market Entry Feature 2 India Market Entry Feature 3 Group 5: Cost Reduction Next Generation BTS Cost Reduction of Transceiver Group 6: USEast Contractual Pole Mount Packaging USEast Inc. Feature 2 USEast Inc. Feature 3 USEast Inc. Feature 4 USEast Inc. Feature 5 Group 7: Ungrouped USEast Inc. Feature 1 Total resource consumption: Available capacity - Release 1 Available capacity - Release 2
BTS Software Development
BTS Hardware Development
BSC/BSM Software Development
MTX Software Development
Testers
Documentation
Capital Requirement ($K)
480 50 60 75 0 250
500 0 10 75 0 100
150 250 120 300 100 400
200 140 120 120 450 400
400 200 190 450 400 400
400 60 40 50 50 50
1500 500 200 500 0 300
10 3 5 7 3 5
100 0 200 100
0 0 0 0
250 100 150 300
100 250 0 200
200 150 100 200
0 50 20 30
50 0 0 50
5 4 4 5
450 75 400
0 120 120
100 10 100
50 0 0
400 75 200
5 20 10
0 200 200
3 2 4
575 200 0 100
420 100 0 100
400 250 300 150
200 250 250 100
250 250 250 300
200 100 100 25
750 500 300 1200
6 4 6 9
450 150
350 200
375 120
125 0
500 200
200 60
150 1000
8 3
400 200 400 150 75
180 0 0 0 180
300 400 600 400 225
50 250 500 125 225
400 250 500 400 300
150 50 200 150 60
500 25 100 1000 750
4 4 4 8 6
100 5040 3000 3000
0 2455 1200 1200
500 6350 3600 3600
200 4305 2200 2200
400 7365 4000 4000
100 2180 1000 1000
0 9775 6000 5000
2
Risk Level
Page 7 of 10
Estimation of the amount of resources of each type required by the features is based on the knowledge of experts. The corresponding estimates and available resource capacity bounds are given in Table 1. Features are grouped, and there are individual access rights for stakeholders that are allowed to vote on each
group of features. Table 1 shows the group for each feature, while Table 2 identifies which groups of features each stakeholder is entitled to vote on. The seven stakeholders log in to the web-based tool to vote based their perception of the urgency and value of each feature.
Table 2: Stakeholders weights and voting access rights Stakeholders Name S1: DTurner S2: JDoe S3: JJames S4: PPrince S5: Sprint S6: Verizon S7: USEast
Role
Weight
Feature Groups Voting Access Rights
Developer Developer Developer Sales Customer Customer Customer
6 4 6 8 9 3 3
All Groups All Groups All Groups All Groups Group 2 Group 1, Group 2, Group 4, Group 7 Group 2, Group 6, Group 7
Various plans are generated that meet the constraints and resource capacity defined. In the current example we generated five different valid and promising release plans. The five different plans are diversified in that two solutions are considered more different as more individual features are assigned to different releases.
The first five alternative plans generated as “Baseline Plans” are shown in Table 3. The numbers 1 and 2 in the rows of each plan indicate the releases to which the feature in the corresponding column is assigned. Number 3 indicates postponed features (i.e. features not currently scheduled).
Table 3: Structure of the five initial baseline plan solutions generated. 2
3
4
5
6
7
8
3 3 2 2 3
1 1 1 1 1
1 1 1 1 1
2 2 1 2 2
2 2 2 2 2
2 3 2 2 2
1 1 1 1 1
1 1 1 1 1
Features ID# 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Corresponding Scheduled Increments 1 3 1 1 1 2 2 2 2 1 1 2 1 1 1 1 2 1 2 1 1 1 2 2 2 2 1 1 2 1 1 1 1 2 1 2 1 1 1 3 2 2 2 1 1 3 1 1 1 3 2 1 2 1 1 1 3 2 1 1 1 1 3 1 1 1 2 2 1 2 1 1 1 2 1 2 2 1 1 2 1 1 1 2 3
The alternative solutions of “Baseline plans” should be most promising with respect to the original objective function. However, because of all the inherent uncertainty of data and incomplete understanding of the problem, it is not enough to base a decision on a single iteration without incorporating human feedback from analyzing a first set of alternative solutions. During evaluation and re-planning ReleasePlannerTM answers the project manager’s (PM) questions including the following among others: • Risk mitigation – How can project risks be distributed across releases so that all risky features are not in one release? • Resource balancing – one release should not have resource consumption competing with available capacity in that release, while the other release uses little of the available capacity.
alternative plan #1 consumes 75% of resources available for release 1 and 72% of available resources for release 2. A more detailed picture of resource consumption for each resource type is given in Figure 3; for every resource type in the rows, the column shows percentage resource consumption for release 1 and release 2 by each alternative plan. 80
Release 1 Release 2
70
60
Average Resource Consumption (%)
Baseline Plan 1 Baseline Plan 2 Baseline Plan 3 Baseline Plan 4 Baseline Plan 5
1
50
40
30
20
10
In our case study, we touched on some of these issues to arrive at a decision. The average resource consumption across the two releases for each of the alternative baseline plans is shown in Figure 2. In the bar charts,
0
1
2
3 Release Plan Alternatives
4
5
Figure 2: Average resource consumption
Page 8 of 10
Figure 3: Distribution of Resource consumption distribution by each resource type After analyzing the plans, we decided that Feature #1 must be postponed. It is the most risky, requires the greatest amount of resources (see Table 1), and the voting pattern indicates that only stakeholders S2 and S6 favor the features being scheduled. These two stakeholders have very low importance. Plans 3 and 4 scheduled Feature #1 and should not be considered further. We focus our analysis on the other three plans #1, 2, 5. Since all the alternative plans are in the range of 95% quality as per the objective function, we compare risk mitigation and resource balancing in the three plans. The high risk features are those having risk value greater than 5. These include features 4, 14, 16, 17, 18, 22, 23, 24. Baseline Plan #5 has 3 of the risky features in release 1 and 5 risky features in release 2, while the two other plans have risky features uniformly distributed. Plan #5 was ruled out because of uneven risk distribution, lack of resource balancing across releases (see Figure 2), and low added value relative to other plans. Plan 1 has higher added value (99.35% range) and an almost perfect resource balancing compared to Plan 2 as shown
in Figure 2. From the analysis, we chose Plan 1 as the best plan in this iteration. In a typical project, the project manager would present Plan 1 to stakeholders to evaluate their satisfaction levels. If there are conflicts of interests, the generally agreed feature assignments are fixed for the next replanning iteration. By fixing agreed features, the five alternative plans after re-planning will be of higher quality, easier to analyze, accepted by a wider spectrum of stakeholders, and will yield a high degree of confidence and satisfaction for the human decision maker. Since the process is basically the same for the next re-planning iteration and because space is limited, we have not repeated the discussion here. Practical Industrial Experience: iGrafx iGrafx is a product group of Corel Inc. Before using ReleasePlannerTM, iGrafx releases were planned in an informal fashion using a Lotus spreadsheet. The planning process was ad hoc, with program management scanning the features to identify the ones to add to the next release, while the development team estimated how many features could be completed in the time allocated. This RP process had several difficulties,
Page 9 of 10 which the introduction of ReleasePlannerTM has assuaged. iGrafx has run tests on a subset (about 250 features ranked by three stakeholders) of their database and reported encouraging results. The iGrafx planning team is more satisfied that they can now define a plan that looks three releases into the future instead of only one release. iGrafx stakeholders are now involved earlier and are more likely to endorse final release plans. The next stage is to define releases using the full set of 800 features ranked by seven stakeholders. Practical Industrial Experience: Trema Laboratories Inc. Trema Group is a provider of strategic software solutions for the financial industry. As with most software organizations, the RP process is mostly ad hoc using spreadsheets and endless meetings with stakeholders in different locations. The size of the inventory of features, from which release plan is developed, usually contains over 500 features requested to be in future releases. The process of ranking and agreeing on the content of the releases takes several days. After an initial trial, Trema Laboratories Inc. found that ReleasePlannerTM helps manage the challenges in the RP process. The time to generate release plans and alternate release plans because of changing features was drastically reduced. The trial involved a roadmap project consisting of 49 features to be released over a period of one year. At the end of the trial, the general agreement was that ReleasePlannerTM provides benefits to the organization through improvement in the involvement of stakeholders, in stakeholder satisfaction, in re-planning, and in the ease of decision making. Conclusions Software companies are faced with endless product planning challenges: conflicting requirements, complex platform/product and roadmap dependencies, time-tomarket pressures, resource bottlenecks and geographically dispersed stakeholders and project teams. Release planning is an important and integral part of any type of incremental product development. Releases decisions are an important prerequisite for successful software engineering project management (SEPM). Systematic and comprehensive release planning based on meaningful data and estimates combined with a sound methodology provides different types of added value:
•
•
•
•
•
Time savings: Time savings result from support in data gathering, in communication and negotiation between stakeholders and in automatically generating release plan alternatives for varying problem instances. Higher flexibility by quick re-planning: Features and their estimated efforts, resources, objectives and budgets are changing quite frequently. Intelligent tool support allows us to address all these changes quickly and in the best possible way. Better match of customer needs: Comprehensive stakeholder involvement and the opportunity to prioritize features from their perspective give a bigger chance to address customer needs and to optimize the product features accordingly. Improved time to market: Since the appropriate selection of requirements are delivered in the release, the product gets to market with these required features. This potentially leads to increased market share through customer satisfaction with the product. More reliable release plans: Planning under consideration of all the key impacting factors and resources creates plans are more likely to be implemented in time and budget.
Acknowledgment The authors would like to thank the Alberta Informatics Circle of Research Excellence (iCORE) for its financial support of this research. Access to real-world data and provision of feedback from real-world projects was provided by Mark Stanford from iGrafx, Joseph Momoh from Trema Laboratories, and Edward Dantsigner from Nortel Wireless Networks. References [1]
[2] [3]
[4]
[5]
[6]
Amandeep, A., Ruhe, G. and Stanford, M., “Intelligent Support for Software Release Planning”, In Proceedings of PROFES’2004, Lecture Notes on Computer Science, vol. 3009, pp 248-262, 2004. Anton, A. I., “Successful Projects Need Requirements Planning”, IEEE Software, 20(6), pp. 44-46, 2003. Bagnall, A. J., Rayward-Smith, V. J., and Whittley, I. M., “The Next Release Problem,” Information and Software Technology, 43 (14), pp. 883-890, 2001. Briand, L. C. and Wieczorek I.: “Resource Estimation in Software Engineering”, 2nd edition of the Encyclopedia of Software Engineering, Wiley, 2001. Carlshamre, P., “Release Planning in Market-Driven Software Product Development: Provoking an Understanding,” Requirements Engineering 7, pp. 139-151, 2002. Carlshamre, P., Sandahk, K., Lindvall, M., Regnell, B., and Nattoch Dag, J., “An Industrial Survey of Requirements Interdependencies in Software Release Planning,” In Proceedings of the 5th IEEE International Symposium on Requirements Engineering, pp. 84-91, 2001.
Page 10 of 10
[7] [8]
[9]
[10]
[11] [12]
[13]
[14]
[15]
[16]
[17]
Christel, M. G., Kang, K.C., “Issues in Requirements Elicitation”, CMU/SEI-92-TR-12, Sept. 92. M.GCMMI Product Team, “Capability Maturity Model Integration (CMMI®) Version 1.1 Staged Representation,” Carnegie Mellon University, Pittsburgh, PA, Mar. 2002. Denne, M. and Cleland-Huang, J., “The Incremental Funding Method: Data Driven Software Development,” 21(3), pp. 3947, 2004. Greer, D. and Ruhe, G., “Software Release Planning: An Evolutionary and Iterative Approach,” Information and Software Technology, 46(4), pp. 243-253, 2004. Jung, H.-W., “Optimizing Value and Cost in Requirements Analysis,” IEEE Software, 15(4), pp. 74-78, 1998. Karlsson, J. and Ryan, K., “Prioritizing Requirements using a Cost-Value Approach,” IEEE Software, 14(5), pp. 67-74, 1997. Karlsson, J., Wohlin, C., and Regnell, B., “An Evaluation of Methods for Prioritizing Software Requirements,” Information and Software Technology, 39(14-15), pp. 939947, 1998. Nejmeh, B. A. and Thomas, I., “Business-Driven Product Planning Using Feature Vectors and Increments”, IEEE Software, 9(6), pp. 34 – 42, 2002. Lethola, L., Kauppinen, M., and Kujala, S., “Requirements Prioritization Challenges in Practice”, Proceedings PROFES’2004, Lecture Notes on Computer Science, Vol. 3009, pp 497-508. Penny D. A., “An Estimation-Based Management Framework for Enhancive Maintenance in Commercial Software Products,” In Proceedings of International Conferenc”, e on Software Maintenance (ICSM), pp. 122130, 2002. Ruhe, G. and Ngo-The, A., “Hybrid Intelligence in Software Release Planning”. International Journal of Hybrid Intelligent Systems, 1(2004), pp. 99-110, 2004.
Authors Dr. Ruhe holds an Industrial Research Chair in Software Engineering at University of Calgary and is an iCORE Professor since July 2001. Dr. Ruhe’s main results and publications are in software engineering decision support, software re-lease planning, requirements and COTS selection, measurement, simulation and empirical research. From 1996 until 2001 he was deputy director of the Fraunhofer Institute for Experimental Software Engineering. He is the author of two books, several book chapters and more than 120 publications. Dr. Ruhe is a member of the ACM, the IEEE Computer Society and the German Computer Society GI.
Omolade Saliu is a PhD candidate in Computer Science Department; and a member of the Laboratory for Software Engineering Decision Support at the University of Calgary, Canada. He holds a Bachelor of Technology (B.Tech.) degree in Mathematics/Computer Science from the Federal University of Technology, Minna, Nigeria (1998). He obtained his Master of Science degree in Computer Science from King Fahd University of Petroleum & Minerals, Saudi Arabia (2003). His research interests include Software Metrics
and Measurement, Software Engineering Decision Support, Software Process-related issues and Soft Computing. He is a member of the IEEE Computer Society.
