Performance Management in Software Engineering

Performance Management in Software Engineering

Markus Ilg (Vorarlberg University of Applied Sciences, Austria) and Alexander Baumeister (Saarland University, Germany)
Copyright: © 2011 |Pages: 18
DOI: 10.4018/978-1-60960-587-2.ch605
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Performance measurement in software engineering has to meet a multiplicity of challenges. Oftentimes, traditional metrics focus on sequential development instead of using incremental and iterative development. Output is measured on a pure quantitative (e.g., SLOC), quality-disregarding basis. A project’s input is hard to assign properly using enterprise-unspecific forecasting tools which have to be calibrated at first and which do not account for time preferences. Requirements necessary for behaviourally adjusted project management and control are rarely discussed. Focusing on these shortcomings, this paper proposes an enterprise-specific approach which combines lifecycle and activity based costing techniques for software development following the incremental and iterative Unified Process model. Key advantages are calibration effort can be avoided, project management decisions are supported by a clear managerial accounting emphasis, precise milestone-depending cost objectives can be determined as the basis for personnel management and control of development teams, and cost and time variance analysis can be supported in a sophisticated way.
Chapter Preview
Top

Introduction

The challenges of performance measurement as a tool of project management in software engineering are twofold. On the one hand an efficiency control requires adequate metrics to assess the productivity of software development by means of input-output-relations. The multitude of existing metrics already clarifies the missing unambiguousness in this field: for an up to date and broad overview of software metrics research see Kitchenham (2010) and for details Anseimo and Ledgard (2003), Choi and Kim (2005), Foulds and West (2007), Kitchenham and Mendes (2004), Maxwell and Forselius (2000) or Pfleeger (2008). Farooquie and Farooquie (2009) provide empirical evidence on performance measurement. Yet, some problems arise by focusing metrics on traditional sequential software development processes instead of using incremental and iterative development (IID) techniques (Tan et al., 2009; Yu, 2010). On the other hand anticipative personnel project management aims to activate behaviour in accordance with the software development objectives. Requirements discussed in responsibility accounting, for example the realistic but challenging setting of objectives or the controllability of influencing variables needed by developers, have to be fulfilled (e.g., Baker, 1992; Baker, 2002; Choudhury, 1986; Otley, 1999; Zimmerman, 2003).

Considering both starting points together, there is some room for improvement: oftentimes, widespread software metrics suppose simple structures of impact by focusing on coding and disregarding other input drivers such as design, analysis or management activities. Besides, the definition of output not only has to account for development progress measured in source lines of code (SLOC) but also for soft facts such as the fulfilment of customers’ demands for example. Hence, output has to be measured with a multi-criterial basis, which accounts for quantitative and qualitative indicators (Krishnan, Kriebel, Kekre, & Mukhopadhyay, 2000). Otherwise, a metric based on SLOC could signal high productivity, whereas in fact the outcome of the project is endangered. Possible risks are unfitting system architectures and user interfaces or the deficient consideration of all stakeholders’ needs. Such accumulation of overseen conceptual non-conformity and the thereby caused bias in productivity more likely deals with traditional process models which are lacking a permanent alignment of objectives. The well-known waterfall archetype for example assumes freezed customer demands for all subsequent stages of development and thus implies a shift of risks towards the future and cost-intensive adjustments (see Figure 1).

Figure 1.

Value at risk due to errors made in the early phases of the waterfall process increases as the project goes on

Complete Chapter List

Search this Book:
Reset