Industrial Engineering - Productivity Engineering in Software Engineering

 Defining Productivity in Software Engineering

Stefan Wagner & Florian Deissenboeck 

Chapter

Open Access

First Online: 08 May 2019

https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_4

1979, Albrecht introduced function points to express the amount of functionality of an information system rather than the size of its code. Based on the specification of a system instead of on its implementation, function points were designed to support early development effort estimation and to overcome limitations inherent to the measurement of LOC, e.g., comparability between different languages. Function points provide a basis for productivity measures such as function points per week or work-hours per function point.

Another aspect related to productivity brought in by agile development was the counting of story points and the calculation of velocity as the number of story points per sprint. However, many proponents of agile development recommend not to use this measure of velocity as a productivity measure because it can lead to unwanted effects. 

Our starting point is Tangen’s [12] Triple-P-Model, which is a well-established model in knowledge work research to differentiate productivity, profitability, and performance as well as the programming productivity Wikipedia article (https://en.wikipedia.org/wiki/Programming_productivity). Especially in software engineering, efficiency is used instead of productivity; we also discuss it and differentiate it from effectiveness. Finally, following Drucker [8], we include a short discussion on the influence of quality on productivity. We discuss each of these terms separately in the following sections and will integrate them afterward.

Performance

The term performance is even broader than productivity and profitability and covers a plethora of factors that influence a company’s success. Hence, well-known performance control instruments such as the Balanced Scorecard [14] do include productivity as a factor that is central but not unique. Other relevant factors are, for example, the customers’ or stakeholders’ perception of the company.

Efficiency and Effectiveness

Efficiency and effectiveness are terms that provide further confusion as they are often mixed up themselves; additionally, efficiency is often confused with productivity. The difference between efficiency and effectiveness is usually explained informally as “efficiency is doing things right” and “effectiveness is doing the right things.” While there are numerous other definitions [12], an agreement prevails that efficiency refers to the utilization of resources and mainly influences the required input of the productivity ratio. Effectiveness mainly aims at the usefulness and appropriateness of the output as it has direct consequences for the customer.

There is still a lot of work to do until we can have a clear understanding of productivity in software engineering. The complexity of capturing good knowledge work is an obstacle in general to unambiguously measuring the productivity of such work. We hope that at least our classification of the relevant terms and the resulting PE Model can help to avoid confusion and to focus further efforts.

UNDERSTANDING SOFTWARE PRODUCTIVITY

WALT SCACCHI

Information and Operations Management Department

School of Business Administration, University of Southern California, Los Angeles, CA 90089-1421, USA

(Appears in Advances in Software Engineering and Knowledge Engineering, D. Hurley (ed.),     Volume 4, pp. 37-70, (1995). December 1994

https://ics.uci.edu/~wscacchi/Papers/Vintage/Software_Productivity.html

What affects software productivity and how do we improve it? This report examines the current state of the art in software productivity measurement. In turn, it describes a framework for understanding software productivity, some fundamentals of measurement, surveys empirical studies of software productivity, and identifies challenges involved in measuring software productivity. A radical alternative to current approaches is suggested: to construct, evaluate, deploy, and evolve a knowledge-based `software productivity modeling and simulation system' using tools and techniques from the domain of software process engineering.

Summary of Software Development Productivity Drivers

The attributes of a software project that facilitate high productivity include:

Software Development Environment Attributes:

Fast turnaround development activities and high-bandwidth processing throughput (may require more powerful or greater capacity computing resources)

Substantial computing infrastructure (abundant computing resources and easy-to-access support system specialists)

 Contemporary software engineering tools and techniques (use of design and code development aids such as rapid prototyping tools, application generators, domain-specific (reusable) software components, etc., used to produce incrementally development and released software products.)

System development aids for coordinating LSS projects (configuration management systems, software testing tools, documentation management systems, electronic mail, networked development systems, etc.)

 Programming languages with constructs closely matched to application domain concepts (e.g., object-oriented languages, spreadsheet languages)

 Process-centered software development environments that can accomodate multiple shifting patterns of small group work structures

Software System Product Attributes:

Develop small-to-medium complexity systems (complexity indicated by size of source code delivered, functional coupling, and functional cohesion)

 Reuse software that supports the information processing tasks required by the application

 No real-time or distributed systems software to be developed

 Minimal constraints for validation of data processing accuracy, security, and ease of alteration

 Stable system requirements and specifications

 Short development schedules to minimize chance for project circumstances to change

Project Staff Attributes:

Small, well-organized project teams. Large teams should be organized into small groups of 3-7 experienced developers, comfortable working with each other

 Experienced software development staff (better if they are already familiar with application system domain, or similar system development projects)

 Software developers and managers who collect and evaluate their own software production data and are rewarded or acknowledged for producing high data value software

 A variety of teamwork structures and the patterns of shifts between them during task performance.

The factors that drive software costs up should be apparent from this list of productivity drivers. Software cost drivers are the opposite of productivity drivers. For example, software without real-time performance should be produced more productively or at lower cost than comparable software with real-time performance requirements.

Also, it should be clear from this list that it is not always possible or desirable to achieve software productivity enhancements through all of the project characteristics listed above. For example, if the purpose of a project is to convert the operation of a real-time communications system from one computer and operating system to another computer-operating system combination, then only some of the characteristics may apply favorably, while others are inverted, occurring only as inhibitors. In this example, conversion suggests a high potential for substantial reuse of the existing source code. However, if the new code added for the conversion affects the system's real-time performance, or is spread throughout the system, then productivity should decrease and the cost increase. Similarly, if the conversion is performed by a well-organized team of developers already experienced with the system, then they should complete the conversion more productively than if a larger team of newly hired programmers is assigned the same responsibility.