ieee impact of budget sdlc10-09

8/7/2019 ieee impact of budget sdlc10-09

http://slidepdf.com/reader/full/ieee-impact-of-budget-sdlc10-09 1/14

Impact of Budget and Schedule Pressure onSoftware Development Cycle Time and Effort

Ning Nan and Donald E. Harter, Member , IEEE

AbstractAs excessive budget and schedule compression becomes the norm in today’s software industry, an understanding of its

impact on software development performance is crucial for effective management strategies. Previous software engineering research

has implied a nonlinear impact of schedule pressure on software development outcomes. Borrowing insights from organizational

studies, we formalize the effects of budget and schedule pressure on software cycle time and effort as U-shaped functions. The

research models were empirically tested with data from a $25 billion/year international technology firm, where estimation bias is

consciously minimized and potential confounding variables are properly tracked. We found that controlling for software process, size,

complexity, and conformance quality, budget pressure, a less researched construct, has significant U-shaped relationships with

development cycle time and development effort. On the other hand, contrary to our prediction, schedule pressure did not display

significant nonlinear impact on development outcomes. A further exploration of the sampled projects revealed that the involvement of

clients in the software development might have “eroded” the potential benefits of schedule pressure. This study indicates the

importance of budget pressure in software development. Meanwhile, it implies that achieving the potential positive effect of schedule

pressure requires cooperation between clients and software development teams.

Index TermsCost estimation, time estimation, schedule and organizational issues, systems development.

Ç

1 INTRODUCTION

RAPID advances in technology have enabled more andmore individuals and companies to compete in the

global marketplace [1], [2], [3]. To succeed, companies mustconstantly look for new ways to act faster and incur less costthan other players in the business. Software companies arenot exceptions. Globalization, outsourcing and open-source

movements have intensified the competition in the softwareindustry [4], [5], [6], [7]. To succeed, software companiesstrive to get their jobs done faster for less money.Consequently, schedule and budget compression hasbecome the norm in today’s software industry [8].

In this study, we attempt to understand how the pressurecreated by budget and schedule compression affects theactual cycle time and cost of software development.Particularly, we intend to see whether improved softwareschedule and cost can be achieved with proper managementof the budget and schedule pressure. An understanding of when and how budget and schedule pressure will positively(or negatively) affect cycle time and cost of softwaredevelopment projects enables managers to rationalize theirbudget and schedule setting policies. More importantly,software management can leverage the beneficial effect of budget or schedule pressure on software development togain more competitive advantage in the global market.

In activities such as sales or sawmill operation, organiza-tion researchers have long recognized a potential positiveeffect of job-related pressure on task performance [9], [10],[11], [12], [13], [14]. Compared with work examined byorganizational studies, software development is different inthat it tends to have higher level of uncertainty and

variability [15]. The distinct characteristics may confoundthe effect of pressure on performance. For example, knowingthat management might reduce a software developmentteam’s estimate, a team could increase its estimate by a safetyfactor (i.e., “padding”) [8]. Such practice is enabled, andmaybe encouraged, by the uncertainty of software develop-ment. The estimation bias diminishes effects of schedule orbudget pressure because it creates artificial resource com-pression without actually increasing the task demand. Inaddition, product size, process maturity, and softwarecomplexity may vary substantially across different projects.The variability of software development has caused incon-

sistent results about the effect of schedule pressure on projectcost (e.g., among [16], [17], [18], [19]). Given the specialcharacteristics of software development, a study with propercontrol of the confounding variables is needed to evaluatethe applicability of the positive effect of pressure identifiedinthe organizational studies to software management.

Furthermore, our concern with effects of pressure ismotivated by the uneven research attention paid to scheduleversus budget pressure. Compared with the literature onschedule pressure, budget pressure has received littleattention. Extant studies often view budget as a fixed value(e.g., [20] and [21]). However, it’s very likely for software

clients to reducea vendor’s estimated budget during contractnegotiation. This warrants a study looking at effects of budget pressure to identify the beneficial or excessive rangeof budget compression.

624 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

. N. Nan is with the Price College of Business, University of Oklahoma,307 West Brooks, Norman, OK 73019. E-mail: [email protected].

. D.E. Harter is with the Whitman School of Management, SyracuseUniversity, 721 University Avenue, Syracuse, NY 13244.E-mail: [email protected].

Manuscript received 28 July 2007; revised 3 July 2008; accepted 17 Feb. 2009;

published online 20 Mar. 2009.Recommended for acceptance by D. Rombach.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TSE-2007-07-0229.Digital Object Identifier no. 10.1109/TSE.2009.18.

0098-5589/09/$25.00 ß 2009 IEEE Published by the IEEE Computer Society

Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.



By borrowing insights from organizational studies, wepropose nonlinear relationships between budget andschedule pressure and development outcomes. With datacollected on software projects from a $25 billion/yearinternational technology firm, this study empirically teststhe relationship between budget and schedule pressure andproject performance. The data set had adequate informationto control for several critical confounding variables, such as

the estimation bias, product size, process maturity, softwarecomplexity, and conformance quality.

The scope of the current study is described by thefollowing concepts and research questions. Budget andschedule pressure is defined by the discrepancy betweenbudget and schedule estimated by the development teamand those negotiated with the client. Software developmentrefers to all the stages starting from initial design throughfinal product acceptance testing. Based on the tradition of software engineering research, the cost of software devel-opment is measured by the total number of person monthslogged by the development team [22] and is referred to as

development effort throughout this paper. Cycle time, orproject duration, is measured by the calendar monthselapsed from the first day of design to final customeracceptance of the product. Our research question is: What isthe impact of budget and schedule pressure on softwaredevelopment cycle time and effort controlling for softwareprocess, size, complexity, and conformance quality?

The rest of the paper is organized as follows: In the nextsection, we review the software engineering literature aboutthe pressure-performance relationship. In Section 3, wedevelop the theoretical foundation and hypotheses of thisstudy. Section 4 describes our research method. Section 5

presents the statistical analysis and results. Section 6examines the results. In the last section, we discussconclusions of the study.

2 LITERATURE REVIEW

In the software engineering literature, researchers have longrecognized the critical impact of resource constraints (e.g.,project schedule or budget) on software developmentoutcomes. Particularly, with respect to project schedule, astream of research has shed light on its effects ondevelopment cycle time or effort. For example, in TheMythical Man-Month, Brooks pointed out that schedule and

manpower were not interchangeable because softwaredeveloper productivity may deviate significantly from aconstant rate as complexity of software projects increases.He stated the viewpoint as Brooks’ Law: “adding man-power to a late software project makes it later” [19]. WithBrooks’ Law as the underlying assumption, Putnamproposed a trade-off function between time and effort inthe Rayleigh curve model [17]. The function indicates thatany compression of schedule has to be compensated by anincrease of effort to maintain the same project cost.Similarly, the COnstructive COst MOdel (COCOMO) [18]predicted that there existed an optimal schedule value; any

compression or lengthening from the optimum would leadto higher cost. Together, Brook’s Law, Putnam’s Rayleighcurve model, and COCOMO represent the early “trade-off”view about impacts of project schedule. As summarized by

Jeffery [16], these early studies concerned the sensitivity of project cost to variation in overall elapsed developmenttime (including both schedule compression and expansion).Although they disagreed on the effect of schedule expan-sion on project cost, all three studies predicted “increasedtotal effort when the manager’s constraint on elapsed timeavailable for development is compressed below the ‘opti-mum’” [16, p. 852].

Subsequent studies in the literature offered more insightsinto the effect of schedule compression on software develop-ment. For example, Jeffery [16] questioned the general-izability of the negative effect of schedule compressionpredicted by earlier studies. By analyzing data fromcommercial software projects in Australia, he found that acompressed schedule could lead to either increased ordecreased development effort. Following Jeffery’s work,Kitchenham [23] found similar results by analyzing anotherdata set from a European software project. Moreover, byreanalyzing the data set behind COCOMO, she found thatthere were schedule-compressed projects that were also

effort compressed, although COCOMO predicted a negativerelationship between the two. These studies attributed thecontradictory findings to difference among research sites,variation among measures of schedule pressure, and missingcontrol variables in the relationship between schedulepressure and development effort [16], [23]. In general, thesesubsequent studies enriched our understanding of therelationship between schedule pressure and developmentoutcomes. Empirically, we see that reduced schedule is notalways achieved at the expense of increased effort; a properlevel of schedule pressure may have beneficial effects onproject outcomes.

In recent years, a few studies have tried to explain theunderlying mechanisms of the impact of schedule pressure.For example, Austin [24] employed an agency framework tocharacterize the strategic behavior of software developersunder schedule pressure. He reduced the concern of soft-ware developers to two main aspects: 1) being singled out asthe only one who cannot finish task on time and 2) beingpenalized for taking quality compromising shortcuts.Results derived from the mathematical model indicate thatcontrary to casual intuition, schedule pressure couldmaintain or even improve software project performance.The underlying mechanism was that software developers

took quality impairing shortcuts to avoid being singled outas the only few who could not meet deadlines. Very tightschedules made it impossible for anyone to meet deadlines.When software developers did not worry about beingsingled out, they would be less likely to take shortcuts andconcern more about quality improvement. Higher qualityincurred less rework, and thereby, reduced developmentcycle time and effort [25], [26], [27].

Using a system dynamics model, Abdel-Hamid et al.[28], [29], [30], [31] proposed multiple causal pathwaysbetween schedule pressure and software developmentoutcomes. They recognized that schedule pressure not only

had a direct impact on productivity by driving developersto work long hours but also produced an indirect impact byaffecting the error generation rate of a project. Results fromthe system dynamics model suggested that contrary to

NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 625




Brooks’ Law, adding more people to a late project did notalways make it completed later; only aggressive compres-sion of schedule could cause higher development effort andlonger cycle time.

Compared with studies about schedule pressure, re-search on budget pressure is rather scanty in the software

literature. Budget constraint is usually discussed as a givencondition (e.g., [20] and [21]) or a value to be minimizedsubject to certain outcomes (e.g., [32]). The few exceptionsonly provide brief arguments about possible impacts of budget compression without performing any formal ana-lysis. For example, the gap between original estimate andcurrent budget is discussed as one of the questions forsoftware feasibility review [33]. In addition, budgetcompression is briefly mentioned as a potential cause of higher development cost [34].

The software literature is summarized in Table 1. Takentogether, the literature has three important implications.

First, the impact of schedule constraint on project outcomesis nonlinear. Particularly, depending on the degree of schedule compression, schedule pressure may have eitherpositive or negative effect on development cycle time and

effort. Second, due to difference in research sites andmeasures, empirical findings alone may be inconclusive(see the discussion in [16]). Thus, theoretical explanation of the underlying mechanisms is warranted to improve thegeneralizability of previous findings. Although the recentstudies have offered some theoretical insights, there is a

need for more fine-grained understanding about thefundamental forces beneath the nonlinear relationshipbetween pressure and job performance. Third, there is aknowledge gap regarding the impact of budget pressure onsoftware development outcomes. While clients commonlyreduce a development team’s proposed budget duringproject negotiation, the impact of budget pressure has notbeen sufficiently addressed in the literature.

To formally characterize the nonlinear impact of schedulepressureandexploretheeffectofbudgetpressure,weborrowinsights from organizational studies. Researchers haveidentified fundamental forces underlying the relationship

between job-related pressure and employee performance[35]. The fundamental forces are an employee’s naturalresponses to stress such as budget or schedule pressure. Theaggregation of the fundamental forces can generate a


TABLE 1Summary of the Software Literature




nonlinear relationship between pressure and performance[9], [10], [11], [36], [37], [38], [39], [40], [41], [42], [43].

3 THEORETICAL DEVELOPMENT

Nearly a century ago, researchers found that performancecould increase with intensity of task demand, but only to acertain point [9]. When intensity of task demand became too

high, performance would decrease. Overall, optimal per-formance tended to occur at an intermediate level of taskdemand while very low or very high level of task demandoften led to poor performance. This nonlinear relationshipbetween task demand and performance is often referred toas Yerkes-Dodson Law.

Organization researchers have shown the generalizabil-ity of Yerkes-Dodson Law to the relationship between job-related pressure (e.g., budget or schedule pressure) andemployee performance [35]. For example, drawing on thetheoretical framework of Yerkes-Dodson law, Singh [35]hypothesized curvilinear impacts of role stressors (i.e., role

conflict, ambiguity, and overload) on salespeople joboutcomes such as performance, job tension, and satisfac-tion. Empirical data from a range of small and large firmssupported the curvilinear effect of role stressors onsalespeople job tension. Meanwhile, in a field experimentabout sawmill workers, researchers found that both workunderload (e.g., mechanically controlled work pact, repeti-tion of short-cycle operations) and overload (e.g., piece-rate rush and high demands of attention) could cause long-term negative effects on workers’ well-being, health, andjob satisfaction. Once workers were given control of thepace and methods of their work, they experienced amoderate level of pressure and showed significantly betterhealth and job satisfaction results. Moreover, in a labora-tory experiment, researchers varied the level of goaldifficulty in a perceptual speed test. They found that therelationship between performance and goal difficultychanged from positive to negative as researchers raisedthe goal difficulty level [44].

In general, the applicability of Yerkes-Dodson law isbased on the understanding of the mechanisms behind thenonlinear relationship between pressure and performance.Researchers have realized that employees’ fundamental ego-needs, such as challenge and pride in their work, mediate thepressure-performance relationship [14]. They see that a low

level of job-related pressure often means a lack of challenge.When employees (e.g., software developers) cannot fulfilltheir fundamental need for challenge, they tend to beinattentive and bored and, thus, do not perform well [45],[46]. On the other hand, a high level of pressure often createstoo much challenge for employees to handle. Their pride inwork may be threatened [14]. Consequently, they tend to feelanxious and frustrated and, hence, perform poorly. Onlyunder an intermediate level of pressure, employees are morelikely to fulfill both needs for challenge and pride in work.Optimal performance usually follows the fulfillment of fundamental ego-needs.

Goal setting theory (see [47] for a review) implies anothermechanism for the nonlinear relationship between pressureand job performance. A goal is the object or aim of a job(e.g., to complete a software product) with a specified

amount of resources (e.g., time and budget) [47]. Higherbudget or schedule pressure means more difficult goals[48], [49]. A major implication of the goal setting theory isthat goal acceptance interacts with goal difficulty and leadsto a nonlinear relationship between goal difficulty and jobperformance [44]. Specifically, goal acceptance is negativelyrelated to goal difficulty, with the transition from accep-tance to rejection usually occurring at an intermediate level

of goal difficulty. Goal difficulty has a positive effect onperformance for accepted goals and a negative effect onperformance for rejected goals. Overall, performance firstincreases with goal difficulty and then levels off ordecreases when goals are too difficult to be accepted.Optimal job performance usually occurs under an inter-mediate level of pressure.

Previous research has extended the pressure perspec-tives from an individual level to a team level. For example,numerous studies have shown that individual-level goalsetting effects can be generalized to teams [47], [50], [51],[52]. The resemblance between individual and team-level

pressure effects is most evident when teams are temporarilyassembled and each member’s expected and actual con-tribution is identifiable. Temporarily assembled teams areexempted from confounding effects of a number of teamcontextual variables such as team history or team culture[51]. Meanwhile, visibility of individual member’s expectedand actual contribution prevents social loafing [53], whichmay cause deviation in a team’s reaction to pressure due tothe individual members’ lack of effort [51].

In this study, we extend the nonlinear relationshipbetween pressure and performance from an individual levelto a team level. This extension is basedon two premises. First,

in the software industry, an essential strategy of projectmanagement is the contracting of IS professionals on atemporary basis [54]. This strategy helps organizations toremain responsive to economic and technological changes byreducing the fixed cost of permanent staff [55], [56]. It makestemporarily assembled software development teams verycommon in the software industry. As discussed above,temporary teams are less affected by team contextualvariables and, therefore, are more likely to show a nonlinearpressure-performance relationship similar to that on anindividual level. Second, the basic methodology of softwareprogramming is divide-and-conquer, that is, dividing theoverall task into parts and working on each part individually[57]. The divide-and-conquer method makes each teammember’s expected and actual contribution identifiable.Thus, the confounding effect of social loafing on thepressure-performance relationship is minimized.

In summary, the organizational studies provide fine-grained understanding of mechanisms underlying thenonlinear relationship between pressure and performance.They have indicated the generalizability of the nonlinearrelationship to studies about effects of continuous taskdemand, such as budget or schedule pressure, on projectteam performance.

3.1 HypothesesIn the software development context, better performance isindicated by shorter cycle time and less development effort.Based on the nonlinear view, shortest cycle time and lowest





development effort tend to occur under an intermediatelevel of budget or schedule pressure while longer cycle timeand higher development effort are associated with very lowor very high level of pressure. Overall, we proposeU-shaped relationships between budget/schedule pressure

and software development cycle time and effort. With theU-shaped view between pressure and software develop-ment performance outcomes, we hypothesized the follow-ing answers to our research question regarding impacts of budget or schedule pressure on software development cycletime and development effort (see Table 2).

4 RESEARCH METHODOLOGY

4.1 Construct Measures

4.1.1 Budget and Schedule Pressure

In the scope of this study, we see three requirements for

effective measures of budget and schedule pressure. First,according to their definition, proper measures shouldindicate the discrepancy between development team-esti-mated budget or schedule and the customer-negotiatedbudget or schedule. Second, the literature on the pressureeffect implies that people have to first perceive the pressureand then respond to it through their performance. AsRobert pointed out that “Software’s problems . . . are aboutexpectations established at the outset of a project muchmore than they are about trouble that happens along theway” [58, p. 19]. Therefore, measures should be taken at theonset of a project rather than at the completion of it. Third,

they should be quantitatively comparable across projectsand teams. This requires a formula that can standardize andquantify the pressure level of a development team.

The literature has not established a consistent measurefor budget or schedule pressure. Budget pressure, oftenreferred to as “budget constraint” or “cost constraint,” isusually measured as the total amount of capital available toa project (e.g., [18]). This measure does not reflect thediscrepancy between team-estimated budget and customer-negotiated budget. Moreover, it is difficult to comparebudget constraints across projects.

Schedule pressure has been assessed by the elapsed time

of a project (e.g., [17], [18]), the ratio between actual elapsedtime and estimated elapsed time (e.g., [16]), the ratiobetween scheduled completion date and forecasted com-pletion date [30], or self-reported values by software

developers and managers [35]. None of these measuresfulfills the three requirements discussed above. The metricsbased on actual elapsed time [16], [17], [18] are post hocrather than ex ante. They do not indicate the pressure levelprior to performance. The self-reported values [35] depend

on people’s subjective opinions. It is difficult to comparepersonal assessments across development teams.Due to a lack of established measures of budget or

schedule pressure, we developed an ex ante measure of pressure:

Budget Pressure ¼

Team-Estimated Budget À Customer-Negotiated Budget

Team-Estimated Budget;

Schedule Pressure ¼

Team-Estimated Time À Customer-Negotiated Time

Team-Estimated Time:

Budget refers to the number of person months of effortallocated for a development project. Cycle time (or projectduration) is the number of calendar months elapsed fromthe first day of design to final customer acceptance of theproduct. At the research site, development teams firstproposed their estimated budget and cycle time with theassistance of an estimation tool. During the negotiationbetween the corporation and clients, the customer usuallyreduced team-estimated budget, with an average reductionof 9.5 percent but never an increase in the budget. Thecustomer was more flexible in negotiations on schedule.

The average schedule reduction was 11.6 percent, but withboth expansion and compression of schedules occurring innegotiations. The customer-reduced budget and modifiedcycle time are recorded in the final contracts after thecompletion of negotiation with the client. The ratio of thechange to the budget or schedule to the original budget orschedule is the measure of pressure. For example, if a team-estimated budget is $10;000 but the negotiation reduces thebudget to $8;000, the budget pressure is 20 percent(($10;000 À $8;000Þ=$10;000 ¼ 0:2 or 20 percent). The nu-merators of the two measures reflect the discrepancybetween team estimates and customer-negotiated budget

or cycle time. We use team-estimated budget or cycle timeas the denominator because taking the ratio between thediscrepancy and the initial team estimates can quantify andstandardize pressure levels across projects and teams.


TABLE 2Budget and Schedule Pressure Hypotheses




Precisely speaking, our measures of budget andschedule pressure only capture the postestimation budgetand schedule compression. They do not account for budgetand schedule pressure that arises and evolves during asoftware development project. Expectations established atthe beginning of a project can be a significant source of variations in software development teams’ performanceduring a project [58]. In this paper, we focus on the

postestimation budget and schedule compression whileacknowledging that the pressure occurring during a projectcan provide a different perspective of the relationshipbetween pressure and performance.

4.1.2 Cycle Time

Cycle time is one dimension of the project performance. It isthe time to develop the software product, i.e., the number of calendar months elapsed from the first day of design tofinal customer acceptance of the product.

4.1.3 Development Effort

Development effort is another dimension of project perfor-mance. In this study, the total number of person monthslogged by the development team from initial designthrough final product acceptance testing constitutes thedevelopment effort.

4.1.4 Control Variables

Software conformance quality is defined as the extent towhich a software product meets quality standard and initialcustomer specifications. Prior studies have found thatsoftware conformance quality, usually measured by thenumber of defects, affects the amount of rework. Subse-quently, the amount of rework has a significant impact ondevelopment cycle time and effort [25], [26]. Given theimportance of conformance quality in development perfor-mance, we controlled for its effect in the data analysis. Here,conformance quality is measured as the number of lines of source code in the product divided by the sum of defectsfound in system testing. Three stages of system testing usinga formal test plan were contractually mandated for allproducts: vendor’s system testing, client system testing witha sample database, and client stress testing with a productiondatabase. Vendor testing was performed by a test groupindependent of the development team. Client testing wasperformed by the client’s technical and user community,

supported by a contractor with expertise in testing complexsystems. This measure of quality is the inverse of the defectdensity [59] used in many previous quality studies. Thispaper adopts the inverse defect density because it offers amore intuitive understanding of the conformance qualityvalues: Higher values mean better conformance quality.

Product size has been recognized as a significant factorin cycle time [60], [61] and development effort [62], [63]. Inthis study, product size is measured by thousand lines of source code in a product. All projects in this study used thesame language, ensuring comparability.

Past research indicated that process maturity [64], [65]

and product complexity [66], [67] have significant impactson software development performance. Process maturity ismeasured by the SEI’s CMM level of maturity. The CMMframework includes 18 key process areas such as quality

assurance, defect prevention, peer review, and training [68].The more CMM process areas that are adopted, the higherthe maturity level is.

Product complexity captures three important dimensionsof complexity: domain, data, and decision complexity [66](see the Appendix, which can be found on the ComputerSociety Digital Library at http://doi.ieeecomputersociety.org/10.1109/TSE.2009.18, for details). Domain complexity is

the level of functional complexity as determined by engineer-ing from the user requirements specification. Data complex-ity refers to the anticipated level of difficulty in developingthe system because of complicated data structures anddatabase relationships. Decision complexity measures thedegree of difficulty in the decision paths and structureswithin the product. Software teams assessed the threedimensionsof product complexity using thecriteria specifiedin the Appendix, which can be found on the ComputerSociety Digital Library at http://doi.ieeecomputersociety.org/10.1109/TSE.2009.18. Each software product managerwas trained in the assessment of complexity by senior

management used in the estimation model [66]. The threedimensions of complexity were assessed ex ante by thesoftware product manager, monitored by quality assuranceto ensure compliance with the estimation process, verified bysenior management for consistency with other projects, andvalidated by an independent assessment of the client’stechnical staff and managers. The three scales of complexityshowed high intercorrelation. Scores of the product complex-ity were computed by taking an average of the threecomplexity scales.

4.2 Regression Models

We developed four research models to test the effects of budget or schedule pressure on development cycle timeand effort of software projects. Their function forms arethe following:

CycleTime ¼ f ðprocess maturity; size; complexity;

quality; budget pressureÞ;ðaÞ

Effort ¼ f ðprocess maturity; size; complexity;

quality; budget pressureÞ;ðbÞ

CycleTime ¼ f ðprocess maturity; size; complexity;quality; schedule pressureÞ;

ðcÞ

Effort ¼ f ðprocess maturity; size; complexity;

quality; schedule pressureÞ:ðdÞ

4.3 Data Collection

To test the hypotheses, we collected cross-sectional data onsoftware projects performed by a $25 billion/year interna-tional technology firm. The company contracts commercial,international, and government clients. The software pro-jects in our data set were developed for a material

requirements planning information system to manage spareparts acquisition.

In the technology firm, assessment of process maturitywas performed by government auditors and corporate





personnel in divisions outside of systems integration. Theseindependent groups used the SEI’s CMM [68] to assess thematurity of the firm’s software development and support-ing activities. We collected process maturity data from theseindependent groups.

Other data were collected by the technology firm andwere audited by the clients to ensure accuracy andaccountability. Cycle time data were retrieved from the

project management scheduling system. Effort data weretracked by the corporate time reporting system. Softwaredefect data were extracted from the Configuration Manage-ment (CM) database. Information related to the estimated,budgeted, and actual duration and cost of softwaredevelopment was manually coded from the electronic andpaper files maintained by the firm.

The technology firm provided an ideal site for thisresearch because its estimation method and managementstrategies can help us eliminate alternative explanations of the impacts of budget or schedule pressure on developmentperformance. First, by using the Software Productivity

Quality and Reliability (SPQR20) automated tool, the firmminimized the “padding” effect. In software industry,development teams often extend their “rational” estimatesof cycle time or cost by a safety factor to counteract the highlevels of pressure [8]. The magnitude of this padding effectvaries across project teams and is hard to assess. As a result,many earlier research findings were confounded by thepadding effect. At our research site, development teamsestimated function point counts and complexity based onuser task requirement specification. These estimates werevalidated by the client to ensure accurate interpretation of the requirements. The function point counts, complexity,and environmental variables were submitted to SPQR20 forbudget and schedule projection. SPQR20 provides aconsistent methodology for estimation of budget andschedule, preventing distortion of the estimates.

To ensure estimation accuracy with SPQR20, develop-ment teams used historical data to calibrate budget andschedule projections. Senior management examined theaccuracy of the methodology annually prior to estimationof the next year’s product development. Historically, theestimation tool underestimated budget by 6.2 percent, i.e.,the teams averaged 6.2 percent budget overruns comparedto estimates. The calibration of SPQR20 with the organiza-tion’s historical data ensured that development team

productivity was accurately reflected in the model estimates.Furthermore, the technology firm implemented a series

of management practices to prevent bias in softwareschedule and cost estimates. These practices correspondedto the bias reduction strategies identified by Peeters andDewey [69]. Each of these practices was performed in theestimation of schedule and budget by the firm during thetime frame of the study. Table 3 summarizes the strategiesrecommended by Peeters and Dewey [69] and how thetechnology firm implemented the corresponding practices.

We found 66 projects with suitable data for the study of budget and schedule pressure (see Table 4 for the descriptivestatistics, and the Appendix, which can be found on the

Computer Society Digital Library at http://doi.ieeecompu-tersociety.org/10.1109/TSE.2009.18, for the correlation ma-trix). The sample size of our study is comparable to previousstudies about software development. In a recent study,

Agrawal and Chari [67] reviewed 18 published softwarestudies and found a median sample size of 37 (see the studyfor more detail).

5 ANALYSIS AND RESULTS

To test the existence of the U-shaped pressure-performancerelationship, we included quadratic terms of budget or

schedule pressure as independent variables in the statisticalmodels. This method has been proved effective by previousstudies (e.g., [70]). Researchers have found economies anddiseconomies of scale [61] in software development. As aresult, a log-log relationship has generally been used to studysoftware effort and cycle time. The appropriateness of a log-log model to our data set is further supported by theDavidson and MacKinnon’s specification test for non-nestedmodels (J-test) [71]. The J-test result shows that a log-logmodel is preferred over semilog and linear models.In the log-log model, we did not take log-transformation of the pressureterms because it is possible for budget or schedule pressurevalues to be 0 or negative. Moreover, since our models focuson the U-shaped relationship between pressure, effort andcycle time, we operationally define the U-shaped functionusing a quadratic term. In this formulation, taking thelogarithm of a quadratic would simply reduce it to twicethe linear term. The specific regression models for budgetpressure analysis are the following:

ln ðCycle TimeÞ ¼ 01 þ 11 ln ðprocess maturityÞ

þ 21 ln ðproduct sizeÞ þ 31 ln ðcomplexityÞ

þ 41 ln ðconformance qualityÞ

þ 51 ðbudget pressureÞ þ 61 ðbudget pressureÞ2;

ð1Þ

ln ðEffortÞ ¼ 02 þ 12 ln ðprocess maturityÞ



þ 52 ðbudget pressureÞ þ 62 ðbudget pressureÞ2:

ð2Þ

The statistical models for schedule pressure analysis arethe following:

ln ðCycle TimeÞ ¼ 03 þ 13 lnðprocess maturityÞ


þ 43 lnðconformance qualityÞþ 53ðschedule pressureÞ þ 63ðschedule pressureÞ2;

ð3Þ

ln ðEffortÞ ¼ 04 þ 14 ln ðprocess maturityÞ



þ 54ðschedule pressureÞ þ 64ðschedule pressureÞ2:

ð4Þ

The models were initially tested with ordinary leastsquares (OLS). However, because data in this study are allfrom the same company, it may be possible that the error

terms are correlated as a result of some common effect. ABreusch-Pagan test of independence indicated that the errorterms aresignificantlycorrelated forboth thebudgetpressureequations ((1) and (2)) (2 ¼ 5:29; p ¼ 0:02) and the schedule





pressure equations ((3) and (4)) (2 ¼ 14:96; p ¼ 0:00).Therefore, we estimated the seemingly unrelated regres-sion (SURE) parameters using a feasible generalized leastsquares (FGLS). Tables 5 and 6 display SURE estimates forthe budget pressure models ((1) and (2)) and the schedule

pressure models ((3) and (4)), respectively.We performed Cook’s Distance test [72] with 1 as the

threshold to look for outliers and influential points in bothbudget and schedule pressure data samples. The results

indicated that no outlier existed in the schedule pressuredata and four outliers existed in the budget pressure data.To ensure the validity of the test results, we removed theoutliers and performed statistical tests on the budget andschedule pressure data sample. The normality assumption

was not rejected using the Kolmogorov-Smirnov test [73].No evidence was found of heteroskedasticity using White’s[74] test. Multicollinearity of explanatory variables wastested using the condition index and variance inflation


TABLE 4Descriptive Statistics

TABLE 3Bias Reduction Strategies




factor. All condition indexes and variance inflation factorswere within acceptable ranges.

The results suggest strong support for our hypothesized

U-shaped relationship between budget pressure and devel-

opment cycle time. As shown in Table 5, there is a positive

and significant coefficient (61 ¼ 11:38; p ¼ 0:05) for the

quadratic term and a negative and significant coefficient(51 ¼ À3:80; p ¼ 0:02) for the linear term of budget pres-

sure in the cycle time equation (1). The statistical results

indicate that budget pressure has a significant U-shaped

effect on development cycle time. Thus, H1 is supported.Statistical results also show strong support for our

hypothesized U-shaped relationship between budget pres-

sure and development effort. In Table 5, the coefficient for

the quadratic term in the effort equation (2) was positive and

statistically significant (62 ¼ 31:39; p ¼ 0:01). Meanwhile,

the coefficient for the linear budget pressure term in the

same equation was negative and significant (52 ¼ À12:23;p ¼ 0:00). These results suggest that budget pressure has a

significant U-shaped effect on development effort. Hence,

H2 is supported.

The results do not support the U-shaped effect of schedule pressure on development cycle time. Althoughthe coefficient of the linear schedule pressure term in (3) isnegative and significant (53 ¼ À0:43; p ¼ 0:01), the coeffi-cient of the quadratic term in the cycle time equation (3) isnot significant (63 ¼ À0:25; p ¼ 0:40) (Table 6). The results

do not support H3 that predicts schedule pressure has asignificant U-shaped effect on software development cycletime.

Finally, we did not find statistical support to thehypothesized U-shaped relationship between schedulepressure and development effort. As shown in Table 6,the coefficient of the quadratic term in the effort equation(4) is negative but not significant (64 ¼ À0:87; p ¼ 0:06).Also, the linear pressure term in (4) is negative and notsignificant (54 ¼ À0:43; p ¼ 0:07). The results do not sup-port the U-shaped curve for H4.

In summary, we see that budget pressure has sig-

nificant U-shaped relationships with software develop-ment cycle time and development effort, controlling forsoftware process, complexity, and conformance quality. Incontrast, schedule pressure does not show a significant


TABLE 5Parameter Estimates of the Budget Pressure Models




U-shaped relationship with development cycle time ordevelopment effort.

6 DISCUSSION

To gain intuition of the nonlinear effect of budget pressure,we plot the components of the linear and squared budget

pressure terms and their combined effect on log-trans-formed cycle time and effort (see Figs. 1 and 2). The linearrepresentations of cycle time and effort appear in Figs. 3 and4. As indicated in the figures, the negative linear terminitially reduces the cycle time and cost; the positive squaredpressure term eventually offsets any time and cost reductiondue to the linear term. The most significant improvementdue to budget pressure occurs in the range of 0-10 percentpressure, identified as beneficial range in the figures. Thecombined curves tend to flatten and become shallow over10 percent, noted in the limited difference range. Excessivebudget compression results in rapidly increasing cycle time

and costs, shown as the excessive compression range.The nonsignificant effect of schedule pressure is some-

what surprising. To further interpret the result, we examinedthe estimates, contracts, and detailed activity schedules of

the sampled projects. An interesting finding is that userinvolvement in the software development process mighthave attenuated the improvement of development cycle timein response to schedule pressure. Specifically, the clients of the projects were involved in the development process byconducting periodic reviews of the deliverables (e.g., designspecifications, test plans, and user manuals), formal life cyclephase reviews (design, detailed design, code development,and testing), and audits. This review and audit time rangedfrom 10 to 20 percent of the product development schedule.When comparing the client review time specified in theestimates with the actual length shown in the schedulecharts, we noticed that clients never shortened their reviewtime even when the projects were under schedule pressure.In addition, the client reviews generally appeared on thecritical path for the product schedules. The lack of elasticityof client review time reduced the variability of the develop-ment cycle time in response to schedule pressure. Thisimplies that achieving the potential positive effect of

schedule pressure requires cooperation between clients andsoftware development teams.

In contrast, the lack of effect of schedule pressure oneffort can be attributed to other causes. Specifically, when


TABLE 6Parameter Estimates of the Schedule Pressure Models




schedule pressure was not accompanied by significantbudget pressure, the project manager had the flexibility of increasing manpower over a shorter period of time withoutaffecting the budget. For example, a project planned for fivemonths with four software developers, when shortened tofour months, could increase staff to five software devel-opers, maintaining 20 person months of effort. The benefitof schedule pressure on effort was negated by the increasein staff by management.

Investigation into whether the performance of theestimation tool affected the results reveals an interestingpattern. For all projects, the estimation tool underestimatedprojects, i.e., the average project resulted in a 6.2 percentbudget overrun compared to the original estimate. How-ever, for projects with beneficial pressure, those with lessthan 10 percent budget pressure, projects, on average,

experienced a 7.7 percent budget underrun. Projects withmore than 10 percent budget pressure had average budgetoverruns of 18.8 percent.

Furthermore, to deepen our understanding of themechanisms underlying the observed pressure effects, weexamined development teams’ reaction to extremely high-and low levels of budget and schedule reductions. At theresearch site, management used the Earned Value approachto track performance against the project baseline during asoftware development project. The baseline is the plannedschedule and budget of the project from final negotiations.The actual schedule and cost performance were monitored

monthly against this baseline to determine if the project wastracking to the planned schedule and budget. We utilize theearned value charts generated during this managementprocess as the lens to open up development teams’ reactionto budget and schedule compression.

Figs. 5 and 6 are the earned value charts for low- andhigh- pressure projects, respectively. In the figures, plannedvalue (PV) is the dollar value of work scheduled. Earnedvalue (EV) is the actual value of work completed; actual cost(AC) is the dollar expenditure that was used to accomplishthe work to date. The latest revised estimate (LRE) reflectsmanagement projection of an underrun or overrun. Thecontract line represents what was negotiated in the contract;adjustments to the contract can occur when functionality ischanged, altering the contract value.

Fig. 5 is an earned value chart for a project with budgetpressure in the 0-10 percent range. Under the lower

pressure scenario, the AC exceeded the PV in the firstmonth, but the development team appeared to be motivatedby this cost overrun and able to recover in the secondmonth. In the sixth month, the EV lagged the PV, indicatingschedule slippage. Again, the team was able to correctbefore the end of the project. The latest revised estimate wasstable, a sign that the development team was able to reactpositively to any temporary schedule or cost slippage andmake adjustments throughout the life of a project toaccommodate low levels of pressure.

Under a higher pressure scenario, as seen in Fig. 6, theeffect of pressure on budget and schedule resulted in costand schedule overruns. In the figure, it appears that there


Fig. 1. Linear and squared component effects of budget pressure on

log(cycle time).

Fig. 2. Linear and squared component effects of budget pressure on

log(effort).

Fig. 3. Effect of budget pressure on cycle time.

Fig. 4. Effect of budget pressure on effort.






variations of different organizations could confound therelationship between pressure and software developmentperformance. Future research that pools data from multipleorganizations can seek to validate and extend the results of this study by adequately controlling the confoundingvariables discussed earlier. Second, the pressure measuresonly capture the postestimation budget and schedulecompression rather than pressure arising during a project.

That prevented us from examining the dynamic impacts of schedule and budget pressure throughout a project. Infuture work, budget and schedule pressure can beevaluated at several points during a development project.An interesting question to examine is whether the effect of pressure found in this study can be applied to later phasesof a project.

7 CONCLUSION

In this paper, we formalize the nonlinear effect of manage-ment pressures on project performance as U-shaped

relationships. The relationships are tested with data froma research site, where estimation bias is consciouslyminimized and information about the potential confound-ing effects such as software process, complexity, andconformance quality is properly tracked. The data analysissupports the U-shaped relationships between budgetpressure and software development cycle time and devel-opment effort. On the other hand, hypotheses about theU-shaped impacts of schedule pressure on developmentcycle time and effort are rejected.

In the highly competitive software engineering industry,companies are looking for ways to make software produc-

tion more efficient. The main contribution of this study is torigorously assess the possibility of achieving improvedcycle time and effort with proper management of pressurein software development. The analysis suggests that thereexists a beneficial range of budget pressure. Such beneficialeffects may also be realized from schedule pressure if software clients cooperate with development teams indealing with schedule compression. In addition to theempirical findings, this study sheds light on the funda-mental mechanisms underlying the U-shaped relationshipsbetween development pressure and software performance.By connecting software development with organizational

studies, this study not only helps to improve the general-izability of related findings from the software literature(e.g., [16], [17], [19], [23]) but also enriches the organiza-tional literature by extending its theories to the softwarecontext. For software management, the theoretical under-standing as well as the empirical findings from this studycan help them attain more effective negotiation strategies,deadline, and budget setting policies, which ultimatelyadds to the competitive advantage of a software company.

ACKNOWLEDGMENTS

The authors would like to thank Dr. Dieter Rombach andthe three anonymous reviewers for their insightful com-ments. They would also like to thank Tara Thomas for herassistance in data collection.

REFERENCES

[1] D. Burdick, “Celestica Transforms Competitiveness withC-Commerce,” Gartner Case Study, Jan. 2000.

[2] D. Chatterjee, R. Grewal, and V. Sambamurthy, “Shaping Up forE-Commerce: Institutional Enablers of the Organizational Assim-ilation of Web Technologies,” MIS Quarterly, vol. 26, no. 2, pp. 65-90, 2002.

[3] T.L. Friedman, The World Is Flat: A Brief History of the Twenty-FirstCentury. Farrar, Straus and Giroux, 2006.

[4] B. Fitzgerald, “The Transformation of Open Source Software,”MIS Quarterly, vol. 30, no. 3, pp. 587-598, 2006.[5] B. Ives and S.L. Jarvenpaa, “Applications of Global Information

Technology: Key Issues for Management,” MIS Quarterly, vol. 15,no. 1, pp. 33-50, 1991.

[6] N. Levina and J.W. Ross, “From the Vendor’s Perspective:Exploring the Value Proposition in Information TechnologyOutsourcing,” MIS Quarterly, vol. 27, no. 3, pp. 331-364, 2003.

[7] K.J. Stewart and S. Gosain, “The Impact of Ideology onEffectiveness in Open Source Software Development Teams,”MIS Quarterly, vol. 30, no. 2, pp. 291-314, 2006.

[8] E. Yourdon, Death March: The Complete Software Developer’s Guide toSurviving “Mission Impossible” Projects. Prentice Hall PTR, 1997.

[9] R.M. Yerkes and J.D. Dodson, “The Relation of Strength of Stimulus to Rapidity of Habit Formation,” J. Comparative andNeurological Psychology, vol. 18, pp. 459-482, 1908.

[10] W.E. Scott, “Activation Theory and Task Design,” OrganizationalBehavior and Human Performance, vol. 1, pp. 3-30, 1966.

[11] R.A. Dienstbier, “Arousal and Physiological Toughness: Implica-tions for Mental and Physical Health,” Psychological Rev., vol. 96,no. 1, pp. 84-100, 1989.

[12] H. Anisman and Y. LaPierre, “Neurochemical Aspects of Stressand Depression: Formulations and Caveats,” Psychological Stressand Psychology, R.W. Neufeld, ed., McGraw-Hill, 1982.

[13] J. Schaubroeck and D.C. Ganster, “Chronic Demands andResponsivity to Challenge,” J. Applied Psychology, vol. 78, no. 1,pp. 73-85, 1993.

[14] M. Frankenhaeuser and B. Gardell, “Underload and Overload inWorking Life: Outline of a Multidisciplinary Approach,” J. HumanStress, vol. 2, no. 3, pp. 35-46, 1976.

[15] R.W. Zmud, “Management of Large Software Development

Efforts,” MIS Quarterly, vol. 4, no. 2, pp. 45-55, 1980.[16] D.R. Jeffery, “Time-Sensitive Cost Models in the Commercial MISEnvironment,” IEEE Trans. Software Eng., vol. 13, no. 7, pp. 852-859, July 1987.

[17] L.H. Putnam, “A General Empirical Solution to the MacroSoftware Sizing and Estimating Problem,” IEEE Trans. SoftwareEng., vol. 4, no. 4, pp. 345-360, July 1978.

[18] B.W. Boehm, Software Engineering Economics. Prentice-Hall, 1981.[19] F.P. Brooks, The Mythical Man Month: Essays on Software Engineer-

ing. Addison-Wesley, 1974.[20] C.S. Raghavendra and S. Hariri, “Reliability Optimization in the

Design of Distributed Systems,” IEEE Trans. Software Eng., vol. 11,no. 10, pp. 1184-1193, Oct. 1985.

[21] G. Ruhe and M.O. Saliu, “The Art and Science of Software ReleasePlanning,” IEEE Software, vol. 22, no. 6, pp. 47-53, Nov./Dec. 2005.

[22] Q. Hu, R.T. Plant, and D.B. Hertz, “Software Cost EstimationUsing Economic Production Models,” J. Management InformationSystems, vol. 15, no. 1, pp. 143-163, 1998.

[23] B.A. Kitchenham, “Empirical Studies of Assumptions ThatUnderlie Software Cost-Estimation Models,” Information andSoftware Technology, vol. 34, no. 4, pp. 211-219, 1992.

[24] R.D. Austin, “The Effects of Time Pressure on Quality in SoftwareDevelopment: An Agency Model,” Information Systems Research,vol. 12, no. 2, pp. 195-207, 2001.

[25] K.T. Abdel-Hamid and E.S. Madnick, “Lessons Learned fromModeling the Dynamics of Software Development,” Comm. ACM,vol. 32, no. 12, pp. 1426-1455, 1989.

[26] W.S. Humphrey, A Discipline for Software Engineering. Addison-Wesley, 1995.

[27] R.D. Banker, G.B. Davis, and S.A. Slaughter, “Software Develop-ment Practices, Software Complexity, and Software Maintenance

Performance: A Field Study,” Management Science, vol. 44, no. 4,pp. 433-451, 1998.[28] K.T. Abdel-Hamid, “The Economics of Software Quality Assur-

ance: A Simulation-Based Case Study,” MIS Quarterly, vol. 12,no. 3, pp. 395-411, 1988.





[29] K.T. Abdel-Hamid, “The Dynamics of Software Projects Staffing:A System Dynamics Based Simulation Approach,” IEEE Trans.Software Eng., vol. 15, no. 2, pp. 109-119, Feb. 1989.

[30] K.T. Abdel-Hamid, K. Sengupta, and D. Ronan, “Software ProjectControl: An Experimental Investigation of Judgment with FallibleInformation,” IEEE Trans. Software Eng., vol. 19, no. 6, pp. 603-612,June 1993.

[31] K.T. Abdel-Hamid, K. Sengupta, and C. Swett, “The Impact of Goals on Software Project Management: An ExperimentalInvestigation,” MIS Quarterly, vol. 23, no. 4, pp. 531-555, 1999.

[32] M.E. Helander, Z. Ming, and N. Ohlsson, “Planning Models forSoftware Reliability and Cost,” IEEE Trans. Software Eng., vol. 24,no. 6, pp. 420-434, June 1998.

[33] S. McConnell, “Feasibility Studies,” IEEE Software, vol. 15, no. 3,pp. 119-120, May/June 1998.

[34] K. Srinivasan and D. Fisher, “Machine Learning Approaches toEstimating Software Development Effort,” IEEE Trans. SoftwareEng., vol. 21, no. 2, pp. 126-137, Feb. 1995.

[35] J. Singh, “Striking a Balance in Boundary-Spanning Position: AnInvestigation of Some Unconventional Influences of Role Stressorsand Job Characteristics on Job Outcomes of Salespeople,”J. Marketing, vol. 62, no. 3, pp. 69-86, 1998.

[36] M.G. Weinberg, The Psychology of Computer Programming. VanNostrand Reinhold Company, 1971.

[37] H. Selye, The Stress of Life. McGraw-Hill, 1956.[38] R.G. Stennett, “The Relationship of Performance Level to Level of

Arousal,” J. Experimental Psychology, vol. 54, no. 1, pp. 54-62, 1957.[39] R.N. Berry, “Skin Conductance Levels and Verbal Recall,”

J. Experimental Psychology, vol. 63, pp. 275-286, 1962.[40] E. Duffy, Activation and Behavior. Wiley, 1962.[41] J.E. McGrath, “Stress and Behavior in Organization,” Handbook of

Industrial and Organizational Psychology, M.D. Dunnette, ed.,pp. 1351-1395, John Wiley, 1976.

[42] H. Sjoberg, “Interaction of Task Difficulty, Activation and WorkLoad,” J. Human Stress, vol. 3, no. 1, pp. 33-38, 1977.

[43] J.R.P. French Jr., R.D. Caplan, and W. Harrison, The Mechanisms of Job Stress and Strain. John Wiley, 1982.

[44] M. Erez and I. Zidon, “Effects of Goal Acceptance on theRelationship of Goal Setting and Task Performance,” J. AppliedPsychology, vol. 69, no. 1, pp. 69-78, 1984.

[45] M. Csikszentmihalyi, “Play and Intrinsic Rewards,” J. Humanistic

Psychology, vol. 15, no. 3, pp. 41-63, 1975.[46] M. Csikszentmihalyi, Beyond Boredom and Anxiety. Jossey-Bass,

1977.[47] E.A. Locke and G.P. Latham, “Building a Practically Useful

Theory of Goal Setting and Task Motivation,” Am. Psychologist,vol. 57, no. 9, pp. 705-717, 2004.

[48] C.N. Parkinson, Parkinson’s Law and Other Studies in Administra-tion. Random House, 1957.

[49] G. Gutierrez and P. Kouvelis, “Parkinson’s Law and Its Implica-tions for Project Management,” Management Science, vol. 37, no. 8,pp. 990-1001, Aug. 1991.

[50] R. Rodgers and J. Hunter, “Impact of Management by Objectiveson Organizational Productivity,” J. Applied Psychology, vol. 76,no. 2, pp. 322-336, 1991.

[51] A. O’Leary-Kelly, J. Martocchio, and D. Frink, “A Review of theInfluence of Group Goals on Group Performance,” Academy of Management J., vol. 37, no. 5, pp. 1285-1301, 1994.

[52] R. Baum, E. Locke, and K. Smith, “A Multi-Dimensional Model of Venture Growth,” Academy of Management J., vol. 44, no. 2, pp. 292-303, 2001.

[53] K.H. Price, “Decision Responsibility, Task Responsibility, Iden-tifiability, and Social Loafing,” Organizational Behavior and HumanDecision Processes, vol. 40, no. 3, pp. 330-345, 1987.

[54] S. Ang and S.A. Slaughter, “Work Outcomes and Job Design forContract versus Permanent Information Systems Professionals onSoftware Development Teams,” MIS Quarterly, vol. 25, no. 3,pp. 321-350, 2001.

[55] S. Nollen and H. Axel, Managing Contingent Workers. Am.Management Assoc., 1996.

[56] J. Pfeffer and J. Baron, “Taking the Workers Back Out: RecentTrends in the Structuring of Employment,” Research in Organiza-

tional Behavior, B. Staw and L.L. Cummings, eds., JAI Press, 1988.[57] D.P. Darcy, C.F. Kemerer, S.A. Slaughter, and J.E. Tomayko, “TheStructural Complexity of Software: Testing the Interaction of Coupling and Cohesion,” IEEE Trans. Software Eng., vol. 31, no. 11,pp 982-995 Nov 2005

[58] L.G. Robert, “Evolving a New Theory of Project Success,” Comm.ACM, vol. 42, no. 11, pp. 17-19, 1999.

[59] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous andPractical Approach. Int’l Thompson Computer Press, 1997.

[60] R.D. Banker, H. Chang, and C. Kemerer, “Evidence on Economiesof Scale in Software Development,” Information Software Technol-ogy, vol. 36, no. 5, pp. 275-282, 1994.

[61] R.D. Banker and S.A. Slaughter, “A Field Study of ScaleEconomies in Software Maintenance,” Management Science,vol. 43, no. 12, pp. 1709-1725, 1997.

[62] A.J. Albrecht and J.E. Gaffney, “Software Function, Source Linesof Code, and Development Effort Prediction: A Software ScienceValidation,” IEEE Trans. Software Eng., vol. 9, no. 6, pp. 639-648,Nov. 1983.

[63] C.F. Kemerer, Software Project Management Readings and Cases.McGraw-Hill, 1997.

[64] M.S. Krishnan, C.H. Kriebel, S. Kekre, and T. Mukhopadhyay,“An Empirical Analysis of Productivity and Quality in SoftwareProducts,” Management Science, vol. 46, no. 6, pp. 745-759, 2000.

[65] D.E. Harter, M.S. Krishnan, and S.A. Slaughter, “Effects of ProcessMaturity on Quality, Cycle Time, and Effort in Software ProductDevelopment,” Management Science, vol. 46, no. 4, pp. 451-466,Apr. 2000.

[66] C. Jones, Applied Software Measurement: Assessing Productivity andQuality. McGraw-Hill, 1996.

[67] M. Agrawal and K. Chari, “Software Effort, Quality, and Cycle

Time: A Study of CMM Level 5 Projects,” IEEE Trans. SoftwareEng., vol. 33, no. 3, pp. 145-156, Mar. 2007.

[68] M.C. Paulk, C.V. Weber, B. Curtis, and M.B. Chrissis, TheCapability Maturity Model: Guidelines for Improving the SoftwareProcess. Addison-Wesley, 1995.

[69] G. Peeters and G. Dewey, “Reducing Bias in Software ProjectEstimates,” CrossTalkThe J. Defense Software Eng., pp. 20-24, Apr.2000.

[70] R.D. Banker and C.F. Kemerer, “Scale Economies in New SoftwareDevelopment,” IEEE Trans. Software Eng., vol. 15, no. 10, pp. 416-429, Oct. 1989.

[71] R. Davidson and J. MacKinnon, “Several Tests for ModelSpecifications in the Presence of Multiple Alternatives,” Econome-trica, vol. 49, no. 3, pp. 781-793, 1995.

[72] R.D. Cook and S. Weisberg, Applied Regression Including Computingand Graphics. John Wiley and Sons, 1999.

[73] N. Smirnov, “On the Estimation of the Discrepancy betweenEmpirical Curves of Distribution for Two Independent Samples,”Bull. Math. Univ. of Moscow, vol. 2, no. 1, pp. 3-16, 1939.

[74] H. White, “Heteroskedasticity-Consistent Covariance MatrixEstimator and a Direct Test for Heteroskedasticity,” Econometrica,vol. 48, no. 5, pp. 817-838, 1980.

Ning Nan received the PhD degree in businessinformation technology from the Ross School ofBusiness at the University of Michigan in 2006.She is currently an assistant professor in thePrice College of Business at the University ofOklahoma. Her research interests include man-agement of software development projects, in-group behaviors and time zone effect on global

software development teams, and postadoptiveinformation technology use behaviors.

Donald E. Harter received the MSc and PhDdegrees in management information systemsfrom Carnegie Mellon University in 1996 and2000, respectively. He is currently an assistantprofessor in the Whitman School of Manage-ment at Syracuse University. His researchinterests include measurement of the effectof software processes on software develop-ment costs, schedules, quality, support activ-ities, and software personnel compensation.

He is a member of the IEEE.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


Date post:	08-Apr-2018
Category:	Documents
Upload:	bunty-dillikar
View:	225 times
Download:	0 times

ieee impact of budget sdlc10-09

Documents