A simulation model for strategic management process of software projects

The Journal of Systems and Software 86 (2013) 21–37

Contents lists available at SciVerse ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

A simulation model for strategic management process of software projects Masood Uzzafer University of Nottingham, United Kingdom

a r t i c l e

i n f o

Article history: Received 20 August 2011 Received in revised form 17 June 2012 Accepted 17 June 2012 Available online 28 June 2012 Keywords: Strategic management Simulation modelling Decision analysis systems Risk analysis Cost estimation

a b s t r a c t In this study, a simulation model for the strategic management process of software development projects is presented. The proposed model simulates the implications of strategic decisions on factors such as cost, risk, budget and schedule of software projects. The main advantage of the proposed model is that it provides an integrated framework wherein risk management, cost estimation, and project management planning for the strategic management process of software development projects are linked. The results of the simulation of the project management planning determine the budget and schedule required for a project. Different strategic management decisions pose different sets of risks, each of which require different cost commitments. Hence, each strategic decision requires a project management plan with its own unique budget and schedule of software development. Thus, the simulation model estimates the risk and cost under different strategic decisions and maps them according to the project management plans. Therefore, the proposed integrated framework helps identify the best strategic option for the development and management of software projects. The proposed simulation model is nonspecific because it contains generic plug and play components that facilitate the use of any set of risk assessment, cost estimation models and project management tools. Therefore, it provides a flexible solution to software organisations and managers of software development projects. The simulation model is applied to a case study, which showed the effect of different strategic decisions on the risk and cost of the different phases of software development and ultimately on the budget and schedule required to complete the project. It therefore provides critical insights in identifying the best strategy for the development of software projects. © 2012 Elsevier Inc. All rights reserved.

1. Introduction As the complexity of software development projects grows, new solutions are needed for the development and management of software projects. Today’s turbulent technological and market environment, fuelled by innovative technological advancements and market competition, has added new dimensions to the management and development of software projects. Therefore, decision making in software development has become more strategic than ever. Consequently, organisations and managers of software development projects not only have to consider project development activities, but also decide which strategic decisions are critical for the effective and efficient development and management of software projects. Therefore, the strategic management of software projects is no longer a choice but a necessity. Software organisations have to make strategic decisions regarding the strategic management of software projects, each of which has a varying degree of impact on the project parameters during

E-mail address: [email protected] 0164-1212/$ – see front matter © 2012 Elsevier Inc. All rights reserved. http://dx.doi.org/10.1016/j.jss.2012.06.042

different phases of the project. Strategic decision making occurs in the early stages of software projects and, at that time, complete information about projects is not known. Therefore, modelling and simulation of the strategic management process provide an alternative to strategic decision making. Formulation of strategies is the main responsibility of management and project managers execute and implement these strategies. Therefore, formulation of successful strategic management plans requires the collaboration of business and project managers (Jacques and Andre, 2007). The strategic management process is about designing and undertaking decisions of strategic importance in order to manage and control strategic project parameters. If the implications of different strategic decisions on strategic project parameters are not properly understood, undesirable management and development options may be selected. Therefore, the scope of strategic management focuses on the overall management of projects and defines and sets the direction of the project development activities (Papadakis and Barwise, 1997) while project management ensures the implementation of the strategic decisions (Jacques and Andre, 2007). Therefore, projects must have strategic management plans that are mapped to the project management plans (Shenhar,

22

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

1999). For example, an organisation makes a strategic decision to develop and test a specific software project internally. However, it could alternatively plan to develop the software project internally but outsource the testing phase. These two strategies have different sets of risks that require different cost commitments. Hence, both strategies would have different implications on the project management plan with their own unique costs to the budget and schedule. When multiple strategic options exist for a particular software development project, quantifying the parameters of strategic importance using simulations of the strategic decisions highlights the implications of each strategic decision on the project management plan. Therefore, simulation of the strategic management process requires estimating the strategic importance of each parameter for each strategic decision and understanding how these quantified parameters shape project management plans. Simulation models help to understand the particular features of a process, which allows better management and control of these features. Simulation and modelling for software development processes are utilised in a variety of ways, including strategic management of software projects (Kellner et al., 1999). Simulation models provide ways to examine the consequences of strategic decisions on strategic project parameters and project management plans and therefore help software organisations select the best strategic decision that suits their resources, budget, risk tolerance and management style. Therefore, simulation of strategic management process supports decision making by identifying those strategic decisions that are beneficial for the development of software projects. Therefore, rather than implementing strategic management decisions directly in real software development plans, simulations reduce the risk of making wrong decisions (de Juan et al., 1999; Law and Kelton, 1991). The field of software engineering is rapidly expanding, but it has not been able to benefit from the research that has taken place in the business and strategic management domains, which has created a need to establish links between software engineering and strategic management (Kakihara, 2006). Software projects can benefit from strategic management practices that address the challenges of rapid expansion of software development activities. Some research works study the development of software projects from the business perspective of strategic management (Cusumano, 2004; Cusumano and Selby, 1995; MacCormack, 2001). While, some studies are conducted from the software perspective by applying strategic management practices to software development projects (Kiper and Feather, 2005; Kakihara, 2006; Williford and Chang, 1999). However, research material for the strategic management of software development projects is scarce in the field of software engineering. This limited knowledge of strategic management impacts the development of software projects in the wake of a rapidly changing technological and market environment. In addition, a framework of strategic management for software projects, which can map strategic decisions with parameters of strategic importance and connect them with project management plans, has not yet been developed. This research presents a simulation model for the strategic management of software development projects. The model emphasises the effects of strategic decisions on strategic parameters of software projects and explains how these affect project management plans. Hence, it is an integrated framework of strategic management, which links the strategic decisions with project parameters and project management plans. The proposed simulation model is generic in nature because it consists of generic components with well-defined interfaces. Therefore, any estimation and assessment models and project management planning tools can be used in the simulation. Furthermore, the research work presents a MATLAB© -based simulation application, which implements the

proposed simulation model for software projects and facilitates a better understanding of the integrated simulation framework for the strategic management of software development projects. This research paper is organised into the following sections. Section 2 discusses current software development and strategic management process models for software projects and explains how such processes can be further improved. Section 3 presents the modelling requirements and discusses strategic parameters along with project development phases that are adopted for constructing the proposed strategic management model for software development projects. Further, it explains the modelling techniques to choose the best technique for the proposed simulation model. Section 4 presents the integrated framework of the strategic management process simulation model. Section 5 discusses the construction details of the proposed simulation model and presents the risk assessment, risk management and cost estimation models and project management tool that were used in the construction of the simulation model. It further presents a MATLAB© based simulation application, which implements the proposed model of the strategic management process. Section 6 lists the procedures used to validate the proposed simulation model and the simulation application. Section 7 discusses a case-study using the simulation application and shows how strategic decisions are transformed into quantified parameters through simulations and how these parameters are mapped to project management plans. Lastly, Section 8 presents the conclusion to this research paper. 2. Process models for software projects Development and management processes for software projects are defined as a set of activities, methods, and practices adopted for the effective and efficient development and management of software projects. Therefore, simulation models of software processes simulate different features of the development stages and the management options for software projects. This section explores existing simulation models of software development and strategic management process models, which provide a foundation for further research and development. 2.1. Software development process models The groundwork for the modelling and simulation of software development processes was carried out by Morecroft and AbdelHamid (1983), who proposed a generic software development process simulation model based on the System Dynamics (SD) modelling technique, which was further developed by Abdel-Hamid and Madnick (1989). Madachay (1994) constructed a SD-based simulation model that studied the effects of performance inspections during the software development process. Kouskouras and Georgiou (2007) proposed a simulation model based on the Discrete Event Simulation (DES) technique to simulate different phases of the waterfall model (Boehm, 1988) for software development projects where each development phase transitions to the next phase in an orderly sequence. More recently, hybrid simulation models that integrate SD and DES have been proposed; for example, Ruiz et al.’s (2004) model simulates the Capability Maturity Model (CMM) for software development projects. 2.2. Strategic management process models Kiper and Feather (2005) presented a model based on the analysis of risk and cost to support strategic decision making in software development projects. They discussed two approaches by which data could be incorporated early in the project lifecycle; these approaches involve the use of either expert opinion or historical data from similar projects. Decision making in the model is

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

23

based on the cost-effective selections from different risk mitigation alternatives. The treatment of risk in the model, however, is overly simplistic and based on single value representations, which are regarded as uncertain (Kitchenham and Linkman, 1997). Williford and Chang (1999) discussed a strategy planning model to generate five-year budgeting and staffing projections for the IT operations of an organisation. Because this model focuses on the business strategy of a specific organisation, it uses proprietary applications that relied on the SD approach. Kakihara (2006) discussed three strategic business development approaches: Position, Resources, and Simple Rules. He adopted a Simple Rule strategy for the strategic management of an internet software development company and argued that, because the internet services were always evolving due to market and technological changes, the development of internet software is an ongoing process. Due to this continuous development activity and dynamic changes in the scope and requirements of the software, the Simple Rule development strategy was the best option.

and addresses a wide range of audiences with varying levels of expertise, including researchers and practitioners. The aim of the proposed simulation model is to help software development organisations and software project managers select the best strategic decisions for the management and development of their software projects.

Modelling and simulation of a strategic management process needs careful consideration of the strategic project parameters. Furthermore, it is equally important to model and simulate different phases of the software development process to understand the changes in the strategic parameters during the different phases of software development. In addition, the selection of the right modelling technique, which represents the characteristics of the process model, is critical.

2.3. Towards improved integrated modelling

3.1. Modelling strategic parameters

Software development organisations and researchers are spending tremendous amount of time and effort in the development of simulations of the software development processes in an attempt to better understand and manage these processes. Kellner et al. (1999) laid out guidelines for building these simulation models of software development processes. They suggested that software development process models should be user-friendly, offering better representation and guidance for easy adaptation by academics and software practitioners to promote further research and validation of these models. In addition, the software development process simulation models should have generic components (i.e., plug and play) so that any set of models and tools can be glued together to construct these simulation models. In addition, because software risk management, risk assessment and cost estimation models are evolving through continuous research, generic simulation models provide a flexible choice to software development organisations. The main drawback of traditional software process simulation models is that they are not user-friendly. This has hampered their adoption by the academic and practitioner communities. In addition, these models simulate specific software processes (for example, Kouskouras and Georgiou, 2007; Ruiz et al., 2004) or redefine software development processes (for example, Abdel-Hamid and Madnick, 1989; Morecroft and Abdel-Hamid, 1983). Hence, organisations are compelled to adopt these processes, although these may not fit very well within their management and organisational structures. Hence, it deprives organisations of the flexibility to choose the appropriate tools and models for the strategic management of their software projects. Furthermore, traditional software development process simulation models largely deal with planning, control, improvement and training of software development processes while the simulation of the strategic management process has received the needed attention. The existing strategic management models present a limited view of the strategic management process and fall short of a framework that can connect the project parameters with project planning in order to facilitate strategic decision making. Therefore, the existing strategic management models need to be further developed so that they can offer more generic solutions. This research work proposes a strategic management process simulation model, which provides a framework that integrates strategic decisions with strategic project parameters and project management plans. Furthermore, the proposed integrated simulation framework is generic in nature and uses components with well-defined interfaces. Therefore, the model is user-friendly

Simulation of the strategic parameters of software development processes provides vital information that is needed to answer key process questions. The most typical parameters involved in software development processes include cost/effort, risk, budget, schedule, quality, and specifications (Law and Kelton, 1991). Researchers have identified cost as the most important parameter in software projects (Pfleeger and Atlee, 2006). There are various cost estimation models for software development projects (Karen et al., 2003). The risk in software development projects represents events that pose a threat to achieving the expected project results (Bannerman, 2008). Risk management of software development projects involves the definition of a set of activities that identify, analyse and manage the impact of risk events (Boehm, 1991). Researchers have suggested that the estimated cost of software development projects should be integrated with the impact of risk (Fairley, 1995; Kansala, 1997; Kitchenham and Linkman, 1997; Gregroy, 2010; Pfleeger and Atlee, 2006). This risk integrated cost helps to abate and manage the adverse impact of risk events and is of critical importance in the strategic management process of software projects (Carstea et al., 2008; Lence and Hayes, 1994; Reilly and Brown, 2004). Project management planning reveals the budget and the schedule of the development of software projects. Budget is the cost in monetary units while the schedule is the timeline of different phases of the development of software projects with specific start and end dates (Pfleeger and Atlee, 2006). The project management planning translates the estimated cost, in man-months, into the budget and the schedule of software projects. Therefore, the proposed strategic management process defines risk, cost, budget and schedule as the major strategic parameters in software development projects. The model maps strategic decisions with the risk and integrates the risk with the estimated cost, while the project management planning translates the risk integrated cost into the monetary units and the timeline which reveals the budget and the schedule of software projects.

3. Modelling requirements for the strategic management process

3.2. Modelling development phases Software development processes are methodologies of software development, which define the activities and phases of software development. A number of software development processes have been proposed, i.e., waterfall, spiral (iterative and incremental) and rapid (Wysocki, 2006); however, each of these processes divides the software development phases in different ways and emphasises different phases. For example, the waterfall model defines the

24

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

transition of a development phase into the next development phase only after the current phase is completed and, therefore, there is no reiteration of any predecessor phases. The waterfall model, therefore, is suitable in an environment where the project requirements are well-understood by all stake holders and proven technologies are used. A spiral model, either iterative or incremental, allows visiting any of the predecessor phases throughout the development lifecycle of the project. The latest development process software projects are the rapid development models, which simulate the continuous evolution of the software design throughout the development lifecycle of the projects. The rapid development models emphasise the development phase over the design phase. An example of rapid models is the agile development model, in which the project manager develops the high level plan based on the basic requirements of the project and the low level planning is carried out by the project team members. The iteration of each phase in the agile development process is a complete project lifecycle from requirements, design, coding and testing. Collyer and Warren (2009) argued that the waterfall model is not suitable for projects in which the requirements continuously evolve. However, the spiral and rapid software development process models can be used in the development of these projects because these models allow feedback that connects a development phase with previous development phases. The proposed strategic management process model in this work depends on feedback; therefore, any software development process that allows feedback can be adopted for the proposed model. Similarly, a number of risk management models for software development projects have been developed (Boehm, 1991; Dorofee et al., 1996; Williams et al., 1999; PMI, 2004; CMMI, 2006). These models define activities and their flow for the risk management of software development projects. Due to the iterative nature of the proposed strategic management process simulation model, it requires the implementation of a risk management model that allows iterations of the project development phases of software projects. Therefore, the CMMI (2006) and the SEI risk management models (Dorofee et al., 1996; Williams et al., 1999) but not the sequential risk management models (for example, Boehm, 1991; PMI, 2004), are suitable for the proposed strategic management process simulation model.

development lifecycle, which can be determined at the different phases of the software development through feedback. DES models enable insights into the performance and evolution of software development processes under changes to project parameters at discrete development phases, which makes them suitable to simulate software development processes. The DES modelling technique is characterised by the following attributes: at least some of the system state variables are random; the system state variables evolve over time in a stochastic process; and changes in the system state variables occur at discrete time segments (Banks et al., 2009; Hlupic and Robinson, 1998; Leemis and Park, 2006; Sweetser, 1999). The random nature of a state variable requires that state variables are predetermined with known probabilities and the stochastic evolution of the system is determined and governed by the random state variables. The strategic project parameters of the proposed strategic management process simulation model are random and change over time in a stochastic manner at predefined, discrete project phases. Another important feature of the simulation model is feedback. Therefore, because the requirements of the proposed simulation model match the features of DES technique, the DES modelling technique is chosen for the proposed strategic management process simulation model. 4. Strategic management process simulation model The proposed strategic management process simulation model is an integrated framework that maps strategic decisions with the cost estimation, risk management and project management planning. The risk management identifies and quantifies the risk while the cost estimation produces the random estimated cost in man-months units and integrates it with the risk. The project management transforms the man-months cost into the budget and the schedule of software projects. The proposed simulation model focuses on the implications of strategic decisions on the cost, risk, budget and schedule for different development phases of software projects. Assuming that  is the random overall impact of risk,  ∈ (0, 1] and  is the random estimated cost, in man-months, the random cost integrated with the impact of risk events, X, can be represented as follows:

3.3. Modelling technique

(Xi )j = (i )j × {(i )j + 1}

An important element in the construction of simulation models is the selection of a modelling technique, which should closely match the characteristics of the model. The SD and DES techniques are widely used in the modelling of software development processes. The SD (Rodrigues and Bowers, 1996) modelling technique is suitable for the modelling of systems and processes with continuous system updates, whereas the DES technique is an appropriate choice for the simulation of systems and processes that evolve over time at pre-defined steps (Leemis and Park, 2006; Banks et al., 2009). DES models are a collection of entities that interact and evolve in discrete time steps towards the accomplishment of some logical end (Law and Kelton, 1991; Sweetser, 1999). The DES modelling technique uses flowcharts (Hebb, 2011), in which entities undergo a stepwise transition from one phase to the next. During each transition, the qualitative and quantitative process parameters are updated through the use of feedback (Kellner et al., 1999). Feedback is a mechanism that connects one point of a process with another; in specific, feedback in a management process gauges how a management decision made at a specific stage in the process affects another stage in complex and indirect ways (Gasparini et al., 2004; Toole, 2005). For example, the decision to change the software testing resources has multiple implications over the entire

where i and j represent the development phase and strategy, respectively. The DES flowchart of the proposed strategic management process simulation model is presented in Fig. 1. The simulation model defines the following generic processes: Strategy Development, Risk Management, Cost Estimation and Project Management. The Strategy Development process conducts the strategic management planning and identifies the different strategic management plans for the development of software projects. The Risk Management process performs the risk assessment for a strategic plan, determines the random overall impact of the risk, (i )j , performs the risk management planning and prepares the risk management plan. Corrective actions at the end of each development phase update the risk management plan. The Cost Estimation process estimates the random estimated cost in man-months,  , and integrates it with the random overall risk, , which results in the identification of the overall cost, (Xi )j . The Project Management process utilises the estimated cost and determines the budget and the schedule for the development of software projects. At the start of the simulation, the business management performs strategic management planning and develops different strategic management plans for the development of a software project. The project manager then selects a strategic management

(1)

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

25

Fig. 1. Simulation model for strategic management process of software projects.

plan, identifies all the risk events associated with the first development phase of the project and assigns an impact to each risk event. In addition, the project manager assigns input parameters for the cost estimation model. The computerised simulation then generates (i=1 )j=1 , and (Xi=1 )j=1 for the first phase, i = 1, and the first strategy, j = 1. The project manager then analyses the feedback from the previous phase and crafts appropriate corrective actions, which updates the risk management plan for the next phase of the project.

The software manager then defines a new set of risk impacts and cost estimation input parameters and simulates the next development phase. This process is repeated for all development phases in order to analyse the complete lifecycle of the software project. At the end of the simulation of the first strategy, the project manager conducts project management planning using the quantified cost and risk from the computerised simulation and determines the corresponding budget and schedule for the software project. The

26

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

Table 1 CMMI risk management steps. CMMI Risk Management Plan – Maturity Level 3 2: Identify and 1: Prepare for Risk Management Analyse Risks A: Identify Risks A: Determine Risk Sources and Categories B: Evaluate, B: Define Risk Parameters Categorise, and Prioritise Risks C: Establish Risk Management Strategy

Table 2 SEI taxonomy-based classes, elements and attributes. Product Engineering

Development Environment

Program Constraints

1. Requirements

1. Development Process a. Formality b. Suitability c. Process Control d. Familiarity e. Product Control 2. Development System

1. Resources

3: Mitigate Risks A: Develop Risk Mitigation Plans B: Implement Risk Mitigation Plans

simulation continues and the process is repeated for all the strategies identified at the beginning of the process. Consequently, at the end of each completed simulation cycle, the cost, risk and the corresponding budget and schedule have been quantified for all strategic management options for the development of the software project. Therefore, the proposed integrated simulation framework identifies the relationship between project development strategies and project management plans and determines the variation and effect of cost, risk, budget and schedule during the different development phases under different strategic decisions. The proposed simulation model utilises generic plug and play components with well-defined interfaces; hence, the model provides the user the flexibility to use different cost estimation simulations, risk assessment models and project management tools. 5. Model construction This section elaborates on the construction of the proposed simulation model using specific risk management, cost estimation models and project management tools. These details will aid software practitioners and academics in utilising the system for software development projects and further research. 5.1. Risk management process model A risk management process model defines a set of activities for the systematic identification, assessment and management of risk. There are various risk management process models available for software development projects (Bannerman, 2008). The prototype of the proposed simulation model uses the CMMI risk management process model (CMMI, 2006), which sets guidelines, shown in Table 1, that are not restricted to any specific phase of software projects. Therefore, these guidelines can be easily adopted for the development of projects, which requires repeating the risk management process during different phases of the development. CMMI divides risk management into three categories: defining a risk management strategy, identifying and analysing risk, and implementing a risk mitigation plan for each identified risk. Each category also has multiple guidelines to help software practitioners during the risk management phase of the software project. The activities of the CMMI risk management model are mapped to the Risk Management component of the proposed strategic management process simulation model. The activities 1A, 1B, 2A and 2B of the CMMI risk management guidelines are utilised during Risk Assessment, the activities 1C and 3A are considered during Risk Management Planning, and activity 3B is used during the Corrective Actions process of the strategic management model. 5.1.1. Software risk assessment model Uzzafer’s (2011) risk assessment model for software projects is adopted; it consists of two stages: risk identification and risk analysis. The risk identification stage identifies and classifies risk events, whereas the risk analysis stage establishes the impact and probability of the identified risk events. Risk identification relies on

a. Stability b. Completeness c. Clarity d. Validity e. Feasibility f. Precedent g. Scale 2. Design a. Functionality

a. Capacity b. Suitability c. Usability

b. Difficulty c. Interfaces

d. Familiarity e. Reliability

d. Performance e. Testability

f. System Support g. Deliverability

f. Hardware Constraints g. NonDevelopmental Software 3. Code and Unit Test a. Feasibility b. Testing c. Coding/Implementation 4. Integration and Test a. Environment b. Product c. System 5. Engineering Specialties a. Maintainability b. Reliability c. Safety d. Security e. Human Factors f. Specifications

3. Management Process a. Planning

b. Project Organisation c. Management Experience d. Program Interfaces 4. Management Methods a. Monitoring b. Personnel Management c. Quality Assurance d. Configuration Management 5. Work Environment

a. Schedule b. Staff c. Budget d. Facilities 2. Contract a. Type of Contract b. Restrictions c. Dependencies 3. Program Interfaces a. Customer b. Associate Contractors c. Subcontractors d. Prime Contractor e. Corporate Management f. Vendors

g. Politics

a. Quality Attitude b. Cooperation c. Communication d. Morale

the Taxonomy Based Questionnaire (TBQ) from the Software Engineering Institute (SEI) (Carr et al., 1993; Higuera and Haimes, 1996; Williams et al., 1999). The TBQ allows the systematic identification of all risk events of software projects using a list of questions to determine the risks in each taxonomy category. It categorises risks into three main classes: Product Engineering, Development Environment and Program Constraints. Each class is further divided into 13 elements and each element is characterised by a set of attributes, shown in Table 2 (Carr et al., 1993), each of which is regarded as a potential risk event. During the risk assessment process, each identified risk event (attribute) is assigned an impact value on the scale of (0,1] based on expert opinion. The impacts of the risk events belonging to any of the SEI risk classes, Program Engineering, Development Environment and Program Constraints, are modelled with a beta distribution, such that pro ∼Beta(˛pro , ˇpro ), dev ∼Beta(˛dev , ˇdev ) and con ∼Beta(˛con , ˇcon ) respectively. Then the random overall risk impact, , is estimated as follows:  = (pro + 1) × (dev + 1) × (con + 1)

(2)

Monte Carlo simulations select random samples of pro , dev and con from their respective distributions and construct the histogram of the overall risk impact, .

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

27

Table 3 COCOMO-II cost drivers and descriptions. Cost drivers

Description

Very low

Low

Nominal

High

Very high

RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP PCAP PCON AEXP PEXP LTEX TOOL SITE SCED

Required Software Reliability Database Size Product Complexity Required Reusability Documentation to match lifecycle Execution Time Constraint Main Storage Constraint Platform Volatility Analyst Capability Programmer Capability Personnel Continuity Applications Experience Platform Experience Language and Tool Experience Use of Software Tools Multi-site operations Required Development Schedule

0.75

0.88 0.93 0.88 0.91 0.95

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1.15 1.09 1.15 1.14 1.06 1.11 1.06 1.15 0.83 0.87 0.92 0.89 0.88 0.91 0.86 0.92 1

1.15 1.19 1.3 1.29 1.13 1.31 1.21 1.3 0.67 0.74 0.84 0.81 0.81 0.84 0.72 0.84 1

0.75 0.89

0.87 1.22 1.16 1.1 1.1 1.12 1.1 1.12 1.1 1.1

1.5 1.37 1.24 1.22 1.25 1.22 1.24 1.25 1.29

Extra high

1.66 1.49 1.67 1.57

0.78

Table 4 Scale factors (Wi ) for COCOMO-II. Wi

Precedentedness Development Flexibility Architecture/Risk Resolution Team Cohesion Process Maturity

PREC FLEX RESL TEAM PMAT

Very low

Low

Nominal

High

Very high

Extra high

4.05 6.07 4.22 4.94 4.54

3.24 4.86 3.38 3.95 3.64

2.43 3.64 2.53 2.97 2.73

1.62 2.43 1.69 1.98 1.82

0.81 1.21 0.84 0.99 0.91

0 0 0 0 0

Table 5 Cost drivers of the early design model.

5.2. Software cost estimation model Estimating the cost of a software project is the process of establishing the amount of effort required to complete it. Researchers have proposed various cost estimation models for software projects (Alkoffash et al., 2008; Boehm, 1981; Johnson, 2009; Karen et al., 2003; Magne and Martin, 2007; Software Technology Support Center Cost Analysis, 2009). Among all the software cost estimation models, the Constructive Cost Model-II (COCOMO-II) (Boehm et al., 2000, 2010) gained widespread acceptance and is widely used to estimate the effort, in man-months, required to complete software projects. COCOMO-II is the latest version of its predecessor COCOMO model and is represented as follows: E = ac × S

bc

× EAF

(3)

where E is the effort in man-months and S is the kilo-lines of delivered logical source code (KDOC) (i.e., if-else is considered as a single line of software code). The effort adjustment factor, EAF, is the product of seventeen software cost drivers, which are shown in Table 3, ac is a constant set to 2.94 and bc is the scaling factor, which is estimated using the following equation: bc = 1.01 + 0.01 ×

s 

Wi

(4)

i=1

where Wi represents the 5 weighted factors shown in Table 4. COCOMO-II is a collection of three adjustable models, which are used during different development stages of the lifecycle of a software project. These stages are defined as Application Composition, Early Design, and Post Architecture. The Application Composition defines the software prototyping and focuses on the interaction of the system and the software, the performance and other high risk areas. The effort for these activities is best estimated using the Application Composition model of COCOMO-II. The next stage in the software project is handled with the Early Design model, which focuses on issues more advanced than prototyping, such as different alternatives of the software and system. The Post Architecture Model deals with the actual software development. After

Cost drivers

Counter parts in Post-Architecture Model

RCPX RUSE PDIF PERS PREX FCIL SCED

RELY, DATA, CPLX, DOCU RUSE TIME, STOR, PVOL ACAP, PCAP, PCON AEXP, PEXP, LTEX TOOL, SITE SCED

application of the Post Architecture Model, a project development lifecycle has been developed and the risks inherent in the software project are understood and established. The Early Design model of COCOMO-II uses the seven cost drivers shown in Table 5 for the calculation of the EAF, while the Post Architecture Model uses all 17 cost drivers listed in Table 3. The Post Architecture COCOMO-II Model is considered for the construction of the proposed simulation model. Software project managers prefer single value representations of parameters, instead of probabilistic notations. However, researchers regard single value representation of project parameters as uncertain and propose modelling the random estimated cost of software projects (Kitchenham and Linkman, 1997) using a Gamma distribution,  ∼ (k, ), where the parameters k and  define the shape and spread of the distribution, respectively. The expectation of the Gamma distribution is defined as E[·] = k. The single value estimate of cost, E, is mapped to the expectation of the Gamma distribution, E → E[ ], from which the corresponding distribution parameters are estimated. Kitchenham and Linkman (1997) presented a model of cost using a Gamma distribution with an expected estimated cost of 200 man-days, which is best approximated by  (k = 2,  = 100), such that E[·] = k = 2 × 100 = 200. The spread parameter, , is shown to be highly relevant to the expectation E[·] because higher expectations need longer distribution spreads; however, the shape parameter, k, can be treated as a constant. Therefore, in order to model the cost,  , the

28

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

shaping parameter, k, is kept constant and the spread parameter is estimated from k and E[·]. 5.3. Project development phases The spiral, iterative and incremental model for the development of software projects is utilised in the construction of the proposed strategic management process simulation model. In this model, each spiral iteration is considered a complete development cycle and the software is incrementally built through the successive iteration of phases. Furthermore, four software development phases in the proposed model were defined. These are design, development, testing and integration, and i = [1, 2, 3, 4] represent each development phase, respectively. 5.4. Project management planning The project management process of the proposed simulation model determines the budget and the schedule of software projects. The project management process evaluates the quantified cost and risk parameters and uses a project planning tool to model the budget and the schedule of software projects. The construction of the proposed model uses Microsoft Project 2007© for the project management planning. The project resources are defined as the human resources and the resource utilisation is represented in units. For example, if a resource utilised 8 h a day, the utilisation units are 100%; consequently, increasing the utilisation units to 150% increases the utilisation hours to 12 h per day. The Microsoft Project 2007© uses the (work = duration × units) model to define the work effort. Therefore, once the work effort, measured in man-months, is defined and the units are fixed, the project duration, in months, can be estimated. In the proposed simulation model, the work, or the estimated cost in man-months, is predefined because it is obtained through the simulations. In addition, the resource utilisation is fixed at 100%; hence, the project management planning tool, Microsoft Project 2007© , can be used to identify the corresponding budget and schedule. 5.5. Simulation application for strategic management process model A simulation application implements the computerised parts of the proposed simulation model, which include the risk assessment and cost estimation, using the MATLAB© modelling language. The interface of the simulation application is shown in Fig. 2. The simulation application loads the data from an external Microsoft Excel 2007© sheet and performs the cost estimation and risk assessment. The simulation application is capable of evaluating three strategic management plans for the development of a software project and determines the corresponding random estimated cost, (Xi )j , and the overall risk, (i )j , for all the development phases of the project. 6. Validation The validation is conducted in two stages. The first involves the validation of the generic strategic management process simulation model and is performed using the validation framework for conceptual models proposed by Lindland et al. (1994). The second stage is the validation of the simulation application and is performed by two objective tests, Sensitivity and Fidelity, which assess the results of the simulation application. A less rigorous approach is undertaken in the application of these tests due to the limited amount of official data available from software organisations (Sargent, 2004).

Fig. 2. Strategic management application.

6.1. Validation of strategic management process model The model validation framework developed by Lindland et al. (1994) includes the validation of the modelling process as well as the model itself. The validation is described by two quality goals, called Syntactic and Semantic, which are achieved by modelling activities called means. The Syntactic goal ensures that all the statements in the model are syntactically correct whereas the Semantic goal defines the completeness of the model. The subsequent Pragmatic validation ensures that the model is comprehensible to the targeted audiences. 6.1.1. Syntactic validation The Syntactic goal is achieved by the manual examination of the modelling language syntax, which includes the technical documentation that describes the model and the application software that implements the model. The quality in the Syntactic validation process is achieved by the identification and fixing of all syntactical issues. 6.1.2. Semantic validation The Semantic goal defines the completeness of the developed model by means of mapping the technical documentation of the model with the implementation of the model. Consequently, the Semantic validation process helps improve the quality of the model. 6.1.3. Pragmatic validation Pragmatic validation identifies the targeted audiences and ensures that the developed model is comprehensible to all of them. Two reviewers with software engineering academic backgrounds were selected to assess the comprehensibility of the generic model. After examination, the reviewers were able to understand the generic model and correctly identified the input and output parameters. 6.2. Validation of simulation application The Sensitivity and Fidelity objective tests validate the accuracy of the simulation results, taking into account the wide range of predefined sets of inputs. The purpose of the Sensitivity test is to ensure that the output of the simulation application is consistent with the input. The Fidelity test then ensures that the output is comparable

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

Fig. 3. Sensitivity test results.

29

6.2.2. Fidelity test The Fidelity test uses two sets of real software development data; the first is obtained from Fairley’s Telecom’s software project (Fairley, 1995) and second corresponds to Kemerer’s research work, which empirically validates the software cost estimation models (Kemerer, 1987). These data sets are based on the COCOMO model, which has the same base equation as the COCOMO-II model; therefore, assuming that the KDOC of the COCOMO-II is the same as the KLOC of the COCOMO, the data from Kemerer’s and Fairley’s projects can be directly compared to the output of the proposed simulation model. The real data of software projects contains effort estimates in man-months for different project sizes, in which each software project has a different set of overall risk impacts. The cost estimates are generated for the same software sizes using the simulation application. Fig. 4 compares the estimated man-months generated by the simulation for different project sizes with the data obtained from the real software projects. As shown, the estimated man-months are comparable with the real software development experience (Kwak and Stoddard, 2004) if the difference in risk impacts is ignored. 7. Case-study of a software project

with real software development experience. The descriptions and procedures of these tests are discussed in the following sections.

6.2.1. Sensitivity test The Sensitivity test is conducted in two stages. First, the value of the overall risk impact is varied, in the range of (0–1], while the other model parameters are kept constant, and the overall man-months corresponding to the updated overall risk impact are calculated. The results of this test show that the estimated manmonths increase linearly as the overall risk impact increases, as shown in Fig. 3. Second, the overall estimated size (KDOC) of the software project is varied between (0–100] and the resulting overall man-months are determined. As illustrated in Fig. 3, the overall man-months required increases as the size of the software project increases.

This section explores a case-study using the simulation application, in order to understand how the proposed strategic management process simulation model can be used in a real software development environment. 7.1. Case description Consider a software development project undertaken by a software development organisation that lacks software testing capabilities. The business management of the organisation considers the following three strategic alternatives for the development of the software project: Strategy 1: Complete in-house software development and testing. Strategy 2: In-house software development and contract-out the testing.

Fig. 4. Software cost estimations for different software project sizes.

30

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

Strategy 3: Complete in-house development and testing with additional training for software testing. The software manager performs the risk assessment which involves identifying risks associated with each strategy. For example, using Strategy 1, software testing poses a threat to the development of the software project and is therefore a potential risk. The risk events due to this strategy are identified by the Testability and the Testing and Environment attributes of the SEI Product Engineering class, which capture the risk events of testing quality, testing requirements, and testing resources. Furthermore, the Formality and Product Control attributes of the Development Process class depict the risk events associated with the testing plans and processes, while the Staff risk attribute in the Program Constraints class describes the risk event that arises from lack of experience in software testing. Analysis of the risks associated with Strategy 2 results in a different set of risk events. When there are multiple teams and sites involved in the development and testing of a software product, there are coordination, monitoring and communication issues that arise among the distributed sites and multiple teams. These risk events are identified by the Process Control, Monitoring and Communication risk attributes of the Development Environment class, which include the coordination and communication issues between the different teams and sites. Furthermore, contracting out the testing phase of the software project introduces risk events related to the contractors, which are identified by the Type of Contract attribute in the Program Constraints class. Because Strategy 3 requires additional training to enhance the testing capabilities of the organisation, this strategy affects the development activities of the software project and causes software maintenance and reliability issues. These risk events are identified by the Maintainability and Reliability attributes of the Product Engineering class. Training also causes difficulty in dealing with human resources and affects the adequacy of the software specifications; these risk events are identified by the Human Factor and Specification attributes of the SEI Product Engineering class, which capture the risk of staffing needs and specification of the software for testing. The software manager then assigns the risk impact values, for the first (design) phase of the development using Strategy 1, to each identified risk event on a scale of (0–1], that are shown in Table A1, where ph1, ph2, ph3 and ph4 represent the design, develop, test and integrate phases, respectively. Table A1 illustrates which risk events are related to the strategy; furthermore, there are risk events that are not dependent on any strategy but contribute to the overall risk impact of the software project and any risk event that is not identified as a risk is not assigned an impact value. Further, the software manager selects the value of the COCOMO-II input parameters for the first phase using Strategy 1; these are shown in Table A2. The simulation application then generates (i=1 )j=1 and (Xi=1 )j=1 . Fig. 5 illustrates the risk impact histograms for all the SEI classes for the design phase (phase 1) of the software project using Strategy 1, along with the overall risk impact (i=1 )j=1 . The simulation is then continued to study the development, testing and integration phases of the software project. At the start of each phase, the software manager assigns the impact values to all the identified risk events and selects the COCOMO-II parameters. The histograms of the costs and the expectations of the estimated costs, E[(Xi )j ], for the different phases using Strategy 1, (Xi = 1, 2, 3, 4)j=1 , are shown in Fig. 6. During the project management planning, the resources of the software development team were assumed to consist of a software manager and 10 software engineers, out of which 7 are software development engineers and 3 are software test engineers. The software manager is involved in all phases of the software project, the

Fig. 5. Phase I risk impact histogram following Strategy 1.

Fig. 6. Histogram of estimated costs using Strategy 1.

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

31

Fig. 7. Project management resources for Strategy 1.

software development engineers are involved in the design, development and integration phases, and the software test engineers are involved in the testing and integration phases. This resource description is used in the analysis of all three project development strategies. Furthermore, each software development resource (i.e., software manager, software development engineers, software test engineers) is assumed to require a budget of $10,000 per month with two exceptions: (1) under Strategy 2, the budget of the software test engineers is 1.5 times the average cost, or $15,000, because the software test engineers are consultants; and (2) for Strategy 3, the budget of the test engineers is 1.2 times the average cost, or $12,000, to account for the additional training required for software testing. A summary of the project resources and their monthly budgets under Strategies 1, 2 and 3 are shown in Figs. 7–9, respectively. The spiral software development process is modelled in the project management plan assuming three iterations of each software development phase, where each iteration is a complete lifecycle of the software development process from the design to the integration phase. In addition, each development phase is modelled as Finish-to-Start in Microsoft Project 2007© , which means that a successor phase is allowed to start only after its predecessor phase finished. In addition, the last development phase of an iteration, i.e., the integration phase, is connected with the starting phase of the next iteration, i.e., the design phase, by Startto-Finish; therefore, the design phase of the next iteration cycle starts only after the integration phase of the current iteration cycle ends.

7.2. Simulation results The simulations estimate that the expected costs, in manmonths, for all the phases of the development using Strategy 1 are E[(X1 )1 ] = 4.4, E[(X2 )1 ] = 9.98, E[(X3 )1 ] = 20.54 and E[(X4 )1 ] = 18.11 man-months. The overall cost is the sum of the expected costs of each development phase of the software project; therefore, the overall expected cost for Strategy 1 is E[(X1 )1 ] + E[(X2 )1 ] + E[(X3 )1 ] + E[(X4 )1 ] = 53.07 man-months. These expected costs for the different phases of the software development project following all the strategies are shown in Fig. 10. Comparing the expected cost in man-months reveals how cost expectations change for each phase under the different strategies. For example, using Strategy 3, the testing phase requires the highest effort, with a cost of 22.11 man-months, whereas the same phase needs the least work effort under Strategy 2, which has an estimated cost of 3.62 man-months. The design and development phase necessitate an almost equal amount of effort under all strategies and, therefore, the difference in the overall cost for each strategy arises from the testing and integration phases. These quantified simulation results of the cost integrated with risk are modelled using the Microsoft Project 2007© for project management planning, which determines the schedule and the budget for each development phase of the software project. Figs. 11–13 show snapshots of the project planning for Strategies 1, 2 and 3, respectively; each snapshot illustrates the expected cost (work), budget (cost) and schedule (duration) of the project and successive iterations of each phase are labelled 1, 2 and 3. For example, design 1 is the first iteration of the design phase, and design

Fig. 8. Project management resources for Strategy 2.

32

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

Fig. 9. Project management resources for Strategy 3.

Fig. 10. Cost expectations, E(Xi )j , for Strategies 1, 2 and 3. Table 6 Budget for different strategic management plans. Development budget ($) Design Strategy 1 Strategy 2 Strategy 3

44,400 46,500 46,500

Develop 99,900 99,900 99,600

Test 205,500 49,912 254,26

Integrate 181,200 191,250 161,978

Total 531,000 387,562 562,343

2 and design 3 are the second and third iterations of the design phase, respectively. The budget allocations for the development of the software project following all three strategies are shown in Figs. 11–13 and are tabulated in Table 6. The simulations show that the expected cost (work) of all the phases of the software project using Strategy 1 are 4.44, 9.98, 20.54 and 18.11 man-months for the design, development, testing and integration phases, respectively. The project management planning reveals that the design phase activities will last 5.89 months in multiple iterations and each iteration will have duration of 0.19 months. The development, testing and integration phases will span 6.12, 7.14 and 6.25 months, respectively, and the duration of the each iteration is estimated to be 0.42, 1.71 and 0.55 months, respectively. The design, development, testing and integration phases require a budget of $44,400, $99,900, $205,500 and $181,200, respectively. Therefore, using Strategy 1, the total budget for the development

of the software project is approximately $531,000 and requires a schedule of 8.56 months for complete development. Similarly, the expected cost (work) for all the phases of the software project using Strategy 2 are 4.65, 9.9, 3.62 and 16.82 man-months for the design, development, testing and integration phases, respectively. The project management planning reveals that each iteration of the design, development, testing and integration phases has a duration of 0.19, 0.42, 0.3 and 0.51 months, respectively, with a total duration of 4.22 months. In addition, the design, development, testing and integration phases using Strategy 2 will require a budget of $46,500, $99,900, $49,912 and $191,250, respectively, with a total budget of approximately $387,562. Strategy 3 requires a work effort of 4.64, 9.95, 22.11 and 15.35 man-months for the design, development, testing, and integration phases, respectively. The project management planning determined the duration of each iteration of each of the phases to be 0.19, 0.42, 1.84 and 0.47 months. Using Strategy 3, the design, development, testing and integration phases require budgets of $46,500, $99,600, $254,265 and $161,978, respectively, with a total development budget of approximately $562,343 and a total duration of 8.72 months. The estimated cost (work), duration and budget are almost the same for the design and development phases of the project under all the development strategies; slight differences in these parameters were observed in the integration phase. However, the biggest differences were obtained during simulation of the testing phase. These results confirm that the difference in the development strategies arise from how the software should be tested and Strategy 2 requires the lowest budget and the least duration. In Strategy 2, the test engineers are contractors and bring their testing expertise to the project, thereby reducing the amount of work and thus budget required; therefore, this strategy requires a lower budget and less time compared to the other two development strategies despite the fact that the contractors are the most expensive resources of the project. The development schedules of the project for all the strategies are shown in Figs. 11–13 and are tabulated in Table 7. The schedule of the project, using Strategy 1, reveals that the first iteration of the design phase (Design 1) starts on 2/1 and ends on 2/6, the development phase (Develop 1) starts on 2/6 and ends on 2/17, the testing phase (Test 1) then starts on 2/17 and continues through 4/5, and the integration phase (Integrate 1) starts on 4/5 and ends on 4/20. Therefore, the first iteration starts on 2/1 and ends on 4/20. The second iteration of the phases starts on 4/20 with Design 2 and continues through all the phases, finishing on 7/10, at which point, the third iteration starts and continues through 9/27. Therefore, using Strategy 1, the project starts on 2/1 and is completed on

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

33

Fig. 11. Project management plan for Strategy 1.

9/27, with a total time span of 8.56 months. Similarly, simulation of the project management planning reveals the schedules of the project using Strategies 2 and 3, with specific dates and durations. The selection of the best strategy in any software development scenario is the function of the business and project managers as they encompass the strategic value of a project for the organisation. These comparisons allow the business management and project managers to select the strategy that best fits their requirements and interests. The best strategy may not be the one that produces the lowest cost and risk, but the one that best suits the organisation’s resources, desired budget and/or schedule. For example, a

Fig. 12. Project management plan for Strategy 2.

software organisation may want to undertake more risk and allocate a larger budget to stay competitive in the market. Furthermore, other parameters, including specifications and quality, are equally important and therefore need careful consideration. In addition, there are factors outside the scope of the project that might contribute to the selection of the optimal project development strategy, such as project development, managerial environment, market competition and technological changes.

34

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

8. Conclusions

Fig. 13. Project management plan for Strategy 3. Table 7 Project’s schedule for Strategies 1, 2 and 3. Iterations

Design

Develop

Test

Integrate

Strategy 1 1 2 3

2/1–2/6 4/20–4/25 7/10–7/13

2/6–2/17 4/25–5/8 7/13–7/26

2/17–4/5 5/8–6/25 7/26–9/12

4/5–4/20 6/25–7/10 9/12–/9/27

Strategy 2 1 2 3

2/1–2/6 3/12–3/15 4/19–4/24

2/6–2/17 3/15–3/28 4/24–5/7

2/17–2/27 3/28–4/5 5/7–5/15

2/27-3/12 4/5–4/19 5/15–5/29

Strategy 3 1 2 3

2/1–2/6 4/23–4/26 7/12–7/17

2/6–2/17 4/26–5/9 7/17–7/30

2/17–4/10 5/9–6/29 7/30–9/19

4/10–4/23 6/29–7/12 9/19–10/2

A simulation model for the strategic management process of software projects has been proposed. It enables a critical view of the effects of strategic decisions on the cost, risk, budget and schedule of software projects. Different management strategies produce different sets of risk and cost, which result in different budget and schedule requirements. The proposed strategic management process simulation model is an integrated framework that encompasses the simulation of the strategic parameters of cost and risk and the integration of these to project management planning, which helps to models the budget and schedule of software projects. The simulation model therefore helps software development organisations and project managers to make the best strategic decisions for the development of their software projects based on the cost and risk tradeoffs and their effects on the budget and the schedule. The proposed simulation model is generic; thus, it has generic components with plug and play interfaces, which allow any set of risk assessment and cost estimation models to be used and any project management planning tool to be adopted in the construction of the simulation model. The model is designed to be user-friendly such that academics and practitioners can easily adopt the proposed simulation model for further research and development. The construction of the proposed simulation model has been presented in detail, including specific risk assessment, cost estimation models and project management tools. Furthermore, a simulation application, using MATLAB© , is presented and simulates the computerised part of the simulations, which includes risk management and cost estimation. The simulation application provides a better understanding of the simulation model and its usefulness in a real software development environment. Managing a software project requires managing multiple aspects of the project, including cost, risk, budget, schedule, quality and specification. The successful strategic management considers all critical parameters and uses models to simulate these project parameters for a given set of strategic decisions. The limitations of the proposed model include the absence of the quality and specification parameters in the simulations. Therefore, the quest to develop better strategic management process models should continue and future work on the proposed model should include the quality and specifications into the strategic management process. The proposed model provides a foundation for the modelling and simulation of strategic decisions, which can be further extended by the inclusion of other parameters of interest in order to obtain a more comprehensive view of the strategic management process for the development of software projects. In addition to project parameters, there are factors outside the scope of the project that can influence the selection of strategic management decision. This research work can be further expanded to include different risk assessment, risk management and cost estimation models and project management tools to determine the best set of models and tools for the strategic management of software projects. In addition, a decision-support mechanism can be integrated within the model, using a Rule-based Expert System to support the analysis of strategic decisions.

Acknowledgement The author would like to thank an anonymous reviewer whose comments helped improve the quality of the paper.

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

35

Appendix A.

Table A1 Risk impacts (shown as percentages) for Strategies 1, 2 and 3. Where a , b and c represents specific risk events of strategy 1, 2 and 3, respectively. Strategy 1a

Product Engineering Requirements Stability Completeness Clarity Validity Feasibility Precedent Scale Design Functionality Difficulty Interfaces Performance Testabilitya Hardware Constraints Non-Development Software Code/Unit Test Feasibility Testinga Coding/Implementation Integration/Test Environmenta Product System Engineering Specialties Maintainabilityc Reliabilityc Safety Security Human Factorsc Specificationsc Development Environment Development Process Formalitya Suitability Process Controlb Familiarity Product Controla Development System Capacity Suitability Usability Familiarity Reliability System Support Deliverability Management Process Planning Project Organisation Management Exp Program Interfaces Management Methods Monitoringb Personnel Management Quality Assurance Configuration Management Work Environment Quality Attitude Cooperation Communicationb Morale Program Constraints Resources Schedule Staffa Budget Facilities

Strategy 2b

Strategy 3c

ph1

ph2

ph3

ph4

ph1

ph2

ph3

ph4

ph1

ph2

ph3

ph4

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

2 1 4 2 3 1 2

3 2 1 1 5 3 1

3 2 1 1 5 3 1

8 2 1 1 10 3 1

6 2 1 1 9 3 1

3 2 1 1

3 2 1 1

8 2 1 1

6 2 1 1

3 2 1 1

3 2 1 1

8 2 1 1

6 2 1 1

3 1

3 1

3 1

3 1

3 1

3 1

3 1

3 1

2 7 5

2 7 5

2 10 5

2 8 5

2

2

2

2

2

2

2

2

5

5

5

5

5

5

5

5

5 2 5

7 2 5

10 2 5

10 2 5

2 5

2 5

2 5

2 5

2 5

2 5

2 5

2 5

5 3 1 1 8 3

5 3 1 1 8 3

10 8 1 1 10 7

8 6 1 1 10 5

1 1

1 1

1 1

1 1

1 4

1 4

10 4

8 4

5 2

5 2

8 10

8 8

2 2

2 2

5 2

3 1 2 1

3 1 2 1

1 1 2

1 1

1 1

1 1

1 1

4 5 5

4 5 5

4 10 8

4 8 8

4

4

4

4

5

5

8

8

5 2

2 2

2 2

5 2

5 2

2 2

2 2

5 2

5 2

3 1 5 4

3 1 5 4

3 1 2 1

3 1 2 1

3 1 5 4

3 1 5 4

3 1 2 1

3 1 2 1

3 1 5 4

3 1 5 4

1 1 2

7 1 5

7 1 5

1 1 2

1 1 2

7 1 5

7 1 5

1 1 2

1 1 2

7 1 5

7 1 5

2 1 1

2 1 1

3 2 1

3 2 1

3 2 1 1

3 2 1 1

10 3 2 1

8 3 2 1

2 1 1

2 1 1

3 2 1

3 2 1

1 2

1 2

1 2

1 2

1 2 4

1 2 4

1 2 10

1 2 8

1 2

1 2

1 2

1 2

5 2

5 2

5 10

5 8

5

5

5

5

5

5

5

5

2

2

5

5

2

2

5

5

2

2

5

5

36

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37

Table A1 (Continued) Strategy 1a ph1 Contract Type of Contractb Restrictions Dependencies Program Interfaces Customer Associate Contractors Subcontractors Prime Contractor Corporate Management Vendors Politics

Strategy 2b ph2

ph3

ph4

Strategy 3c

ph1

ph2

ph3

ph4

3

3

8

6

ph1

ph2

ph3

ph4

5

5

5

5

5

5

5

5

5

5

5

5

3

3

3

3

3

3

3

3

3

3

3

3

Table A2 COCOMO-II parameters data. Strategy 1

ac bc EAF

Size

Strategy 2

Strategy 3

ph1

ph2

ph3

ph4

ph1

ph2

ph3

ph4

ph1

ph2

ph3

ph4

2.94 0.92 0.32 5

2.94 0.92 0.32 12

2.94 0.94 0.87 8

2.94 0.94 0.78 8

2.94 0.92 0.32 5

2.94 0.92 0.32 12

2.94 0.94 0.15 8

2.94 0.94 0.74 8

2.94 0.92 0.32 5

2.94 0.92 0.32 12

2.94 0.94 0.95 8

2.94 0.92 0.69 8

0.81 1.21 0.84 0.99 0.91

0.81 1.21 0.84 0.99 0.91

1.62 2.43 0.84 0.99 0.91

1.62 2.43 0.84 0.99 0.91

0.81 1.21 0.84 0.99 0.91

0.81 1.21 0.84 0.99 0.91

1.62 1.21 0.84 1.98 0.91

1.62 1.21 0.84 1.98 0.91

0.81 1.21 0.84 0.99 0.91

0.81 1.21 0.84 0.99 0.91

1.62 2.43 0.84 0.99 0.91

1.62 1.21 0.84 0.99 0.91

1 1 1 1 1 1 1 1 0.83 0.87 0.92 0.89 0.88 0.91 0.86 0.78 1

1 1 1 1 1 1 1 1 0.83 0.87 0.92 0.89 0.88 0.91 0.86 0.78 1

1 1 1 1 1 1 1 1 1 1 1 1 1.12 1 1 0.78 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0.78 1

1 1 1 1 1 1 1 1 0.83 0.87 0.92 0.89 0.88 0.91 0.86 0.78 1

1 1 1 1 1 1 1 1 0.83 0.87 0.92 0.89 0.88 0.91 0.86 0.78 1

1 1 1 1 1 1 1 1 0.67 0.74 0.84 0.81 0.81 0.84 0.72 0.92 1

1 1 1 1 1 1 1 1 1 1 1 1 0.88 1 1 0.84 1

1 1 1 1 1 1 1 1 0.83 0.87 0.92 0.89 0.88 0.91 0.86 0.78 1

1 1 1 1 1 1 1 1 0.83 0.87 0.92 0.89 0.88 0.91 0.86 0.78 1

1 1 1 1 1 1 1 1 1.22 1 1 1 1 1 1 0.78 1

1 1 1 1 1 1 1 1 1 1 1 1 0.88 1 1 0.78 1

Wi

PREC FLEX RESL TEAM PMAT Cost drivers RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP PCAP PCON AEXP PEXP LTEX TOOL SITE SCED

References Abdel-Hamid, T.K., Madnick, S.E., 1989. Lessons learned from modeling the dynamics of software development. Communications of ACM 32 (1), 1426–1438. Alkoffash, M.S., Bawaneh, M.J., Al Rabea, A.I., 2008. Which software cost model to choose in a particular project. Journal of Computer Science 4 (7), 606–612. Banks, J., Carson, J.S., Nelson, B.L., Nicol, D.M., 2009. Discrete Event System Simulation, 5th ed. Prentice Hall. Bannerman, P., 2008. Risk and risk management in software projects: a reassessment. The Journal of System and Software 81, 2118–2133. Boehm, B.W., 1981. Software Engineering Economics. Prentice-Hall, Englewood Cliffs, NJ. Boehm, B.W., 1988. A spiral model of software development and enhancement. IEEE Computer 2 (5), 61–72. Boehm, B.W., 1991. Software risk management: principles and practices. IEEE Software 8 (1), 32–41. Boehm, B.W., Abts, C., Brown, W.A., Chulani, S., Clark, B.K., Horowitz, E., Madachy, R., Reifer, D.J., Steece, B., 2000. Software Cost Estimation with Cocomo II. Prentice Hall. Boehm, B.W., Abts, C., Clark, B., Devnani-Chulani, S., 2010. COCOMO-II Model Definition Manual, Version 1.4, Available at: http://editavenue.com/dropoff/ sunset.usc.edu/research/COCOMOII/Docs/modelman.pdf (accessed October 2010). Carr, M.J., Konda, S.L., Monarch, I., Walker, C.F., Ulrich, F.C., 1993. Taxonomy Based Risk Identification, CMU/SEI-93-TR-006. Software Engineering Institute, Pittsburgh, USA.

Carstea, C.-G., Ratiu, I.-G., Patrascu, N., Pearsica, M., David, N., Damian, D., Patrascu, L., 2008. Risk control in strategic management projects. In: MAMECTIS’08 Proceedings of the 10th WSEAS International Conference on Mathematical Methods, Computational Techniques and Intelligent Systems, Corfu, Greece, pp. 182–186. CMMI, P.T., 2006. CMMI for Development, CMU/SEI-2006-TR-008, Version 1.2. Software Engineering Institute. Collyer, S., Warren, C.M.J., 2009. Project management approaches for dynamic environments. International Journal of Project Management 27, 355–364. Cusumano, M.A., 2004. The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad. Free Press, New York. Cusumano, M.A., Selby, R.W., 1995. Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets and Manages People. Free Press, New York. de Juan, M.A., Leon, M.A., Martin-Calero, B., Mendoza, A., de los Ojos, A., Peran, J.R., de Miguel, L.J., 1999. Decision making based on a discrete event simulation tool. In: Proceedings of 7th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA’99, Barcelona, Spain, pp. 335–341. Dorofee, A.J., Walker, J.A., Alberts, C.J., Higuera, R.P., Murphy, R.L., Williams, R.C., 1996. Continuous Risk Management Guidebook. Software Engineering Institute. Fairley, R., 1995. Risk management for software projects. IEEE Software 11 (3), 57–67. Gasparini, M., Margaria, G., Wynn, H.P., 2004. Dynamic risk control for project management. Statistical Methods and Applications 13, 78–88. Gregroy, N., 2010. Improving Cost Estimation with Quantitative Risk Analysis, Available at: http://editavenue.com/dropoff/www.hearne.co.uk/attachments/ Vose ICE Whitepaper v1.1.pdf (accessed October 2010).

M. Uzzafer / The Journal of Systems and Software 86 (2013) 21–37 Hebb, N., 2011. Flowchart Symbols Defined: Flowchart Symbols and Their Meanings, Available at: http://www.breezetree.com/article-excel-flowchart-shapes.htm (accessed October 2011). Higuera, R.P., Haimes, Y.Y., 1996. Software Risk Management, CMU/SEI-96-TR-012. Software Engineering Institute. Hlupic, V., Robinson, S., 1998. Business process modelling and analysis using discrete-event simulation. In: Winter Simulation Conference (WSC’98), pp. 1363–1369. Jacques, B., Andre, B., 2007. The link between project management and strategic management: realising strategy success. In: AFRICON 2007, Windhoek, pp. 1–8. Johnson, K., 2009. Software Cost Estimation: Metrics and Models, Available at: http://edwinlcy.multiply.com/journal/item/264 (accessed December 2009). Kakihara, M., 2006. Strategizing software development: strategic management of internet service development. In: Proceedings of the 2006 International Workshop on Interdisciplinary Software Engineering Research, WISER’06, Shanghai, China, pp. 37–43. Kansala, K., 1997. Integrating risk assessment with cost estimation. IEEE Software 14 (3), 61–67. Karen, L., Bramble, M., Hihn, J., Hackney, J., Khorrami, M., Monson, E., 2003. Handbook for Software Cost Estimation. JPL D-26303, Rev. 0. Jet Propulsion Laboratory. Kellner, M.I., Madachy, R.J., Raffo, D.M., 1999. Software process simulation modeling: Why? What? How? Journal of System and Software 46, 91–105. Kemerer, C.F., 1987. An empirical validation of software cost estimation models. Communications of the ACM, 416–429. Kiper, J.D., Feather, M.S., 2005. A risk-based approach to strategic decision-making for software development. In: Proceedings of the 38th Annual Hawaii International Conference on System Sciences, HICSS’05, Hawaii, p. 313c. Kitchenham, B., Linkman, S., 1997. Estimates, uncertainty and risk. IEEE Software 3, 69–74. Kouskouras, K.G., Georgiou, A.C., 2007. A discrete event simulation model in the case of managing a software project. European Journal of Operational Research 181, 374–389. Kwak, Y.H., Stoddard, J., 2004. Project risk management: lessons learned from software development environment. Technovation 24, 915–920. Law, A.M., Kelton, D.W., 1991. Simulation Modeling and Analysis. New York, McGraw Hill, Inc. Leemis, L.M., Park, S.K., 2006. Discrete-Event Simulation: A First Course. Prentice Hall. Lence, S.H., Hayes, D.J., 1994. Parameter-based decision making under estimation risk: an application to future trading. The Journal of Finance 1 (49), 345–357. Lindland, O.I., Sindre, G., Solvberg, A., 1994. Understanding quality in conceptual modeling. IEEE Software 2 (11), 42–49. MacCormack, A.D., 2001. Product-development practices that work: how internet companies build software. MIT Sloan Management Review 42 (2), 75–84. Madachay, R.J., 1994. A Software Project Dynamics Model for Process Cost, Schedule and Risk Assessment, Available at: http://sunset.usc.edu/ (accessed csse/TECHRPTS/PhD Dissertations/files/Madachy Dissertation.pdf October 2010). Magne, J., Martin, S., 2007. A systematic review of software development cost estimation studies. IEEE Transactions on Software Engineering 33 (1), 33–53. Morecroft, J.D., Abdel-Hamid, T.K., 1983. A generic system dynamics model of software project management. In: Proceedings of the First International Conference of the System Dynamics Society, Massachusetts, USA, pp. 237–252.

37

Papadakis, V., Barwise, P., 1997. Strategic Decisions, 1st ed. Springer. Pfleeger, S.L., Atlee, J.M., 2006. Software Engineering, Theory and Practice, 3rd ed. Pearson International Edition. PMI, 2004. A Guide to the Project Management Body of Knowledge (PMBOK), 3rd ed. Project Management Institute. Reilly, J., Brown, J., 2004. Management and Control of Cost and Risk for Tunneling and Infrastructure Projects, Available at: http://www.wsdot.wa.gov/ NR/rdonlyres/C1DAB840-87B1-4401-9B44-4F57FC31DBBE/0/ReillyBrown CEVPITASingaporepaper2004.pdf (accessed October 2010). Rodrigues, A., Bowers, J., 1996. The role of system dynamics in project management. International Journal of Project Management 14 (4), 213–220. Ruiz, M., Ramos, I., Toro, M., 2004. An integrated framework for simulation-based software process improvement. Software Process: Improvement and Practice 9 (2), 81–93. Sargent, R.G., 2004. Verification and validation of simulation models. In: Proceedings of the 2004 Winter Simulation Conference, Washington, DC, pp. 17–27. Shenhar, A., 1999. Strategic project management: the new framework. In: International Conference on Management of Engineering and Technology, Technology and Innovation Management, PICMET’99, Portland, vol. 2, pp. 382–386. Software Technology Support Center Cost Analysis, G., 2009. Software Development Cost Estimating Guidebook, Available at: http://www.stsc.hill.af.mil/ consulting/sw estimation/estimatingguidebook.html (accessed December 2009). Sweetser, A., 1999. A comparison of system dynamics and discrete event simulation. In: Proceedings of the 17th International Conference of the System Dynamics Society, New Zealand, pp. 979–991. Toole, M.T., 2005. A project management causal loop diagram. In: Proceedings of 21st Conference of Association of Researchers in Construction Management (ARCOM 2005), London, UK, pp. 763–772. Uzzafer, M., 2011. A novel risk assessment model for software projects. In: International Conference on Computer and Management (CAMAN 2011), Wuhan, China, pp. 1–5. Williams, R.C., Pandelios, G.J., Behrens, S.G., 1999. Software Risk Evaluation Method Description, CMU/SEI-99-TR-029. Software Engineering Institute. Williford, J., Chang, A., 1999. Modeling the FedEx IT division: a system dynamics approach to strategic IT planning. Journal of Systems and Software 46 (2/3), 203–211. Wysocki, R.K., 2006. Effective Software Project Management. Wiley Press. Masood Uzzafer has more than 14 years of software development experience in designing and development of different software applications including multimedia, DSP, embedded, mobile and web applications. Mr. Masood has worked for Philips Semiconductors, California, and AlliedSignal Aero-Space, Florida. His research interests are risk management and strategic planning. Mr. Masood received Bachelor of Commerce from University of Karachi in 1988, Bachelor of Electrical Engineering from N.E.D. University, Karachi in 1991 and M.S. in Electrical Engineering from Wayne State University, Detroit, USA in 1994. Currently he is a PhD candidate at University of Nottingham, UK.