The 2GCHAS: A high productivity software development environment

To the user, the most visible feature of the Transportable Applications Executive (TAE) is its very powerful user interface. To the programmer, TAE's user interface, proc concept, standardized interface definitions, and hierarchy search provide a set of tools for rapidly prototyping or developing production software. The 2GCHAS (Second Generation Comprehensive Helicopter Analysis System) project has extended and enhanced these mechanisms, creating a powerful and high productivity programming environment where the 2GCHAS development environment is 2GCHAS itself and where a sustained rate for certified, documented, and tested software above 30 delivered source instructions per programmer day has been achieved. The 2GCHAS environment is not limited to helicopter analysis, but is applicable to other disciplines where software development is important

AUTOMATING SOFTWARE DEVELOPMENT PRODUCTIVITY METRICS

Measurement of software development productivity is needed in order to control software costs, but it is discouragingly labor-intensive and expensive. Computer aided software engineering (CASE) technologies -- especially object-oriented, integrated CASE -- have the potential to support the automation of this measurement. In this paper, we describe automated analyzers for function point and code reuse measurement. Both analyzers take advantage of the existence of a meta-model of the application system, stored within an object repository, which contains the necessary information about the application system. We also propose new metrics for code reuse analysis, including reuse leverage, reuse value and reuse classification. The state-of-the-art automated software metrics analyzers are illustrated in the context of an investment banking industry application.Information Systems Working Papers Serie

Enhancing Software Team Planning and Delivery Performance using Agile Driven Quality Measures: Approach, Results, and Recommendations

Implementing a performance-management program in an agile software-development organization is important to retain sight of software team performance as a whole as well as linking performance-management metrics to business value. The evaluation criteria for software engineers’ performance have been traditionally driven by metrics that don’t fit into agile-development principles. This research implements a measurement metric that aligns with agile-development core values and principles to evaluate engineers in a software engineering firm using the Scrum development method. The research focused on measuring and evaluating the productivity, development efficiency, social skills, team collaboration and breadth of knowledge. Observing the Productivity Index (PI), Actual Productivity for software Engineers (APSE), and Productivity Variance (PV) for individual software engineers and the development team at the end of each sprint helped the development team have a better understanding of its productivity levels in a matter that facilitated planning future sprints. In addition, this productivity measure helped early identification of productivity challenges encountered by several software engineers and productivity identification of productivity challenges encountered by several software engineers. Keywords: Agile development, software teams, process measurement, scrum, productivity, efficiency, software metrics, software project measuremen

A communication channel model of the software process

Beginning research into a noisy communication channel analogy of software development process productivity, in order to establish quantifiable behavior and theoretical bounds is discussed. The analogy leads to a fundamental mathematical relationship between human productivity and the amount of information supplied by the developers, the capacity of the human channel for processing and transmitting information, the software product yield (object size) the work effort, requirements efficiency, tool and process efficiency, and programming environment advantage. An upper bound to productivity is derived that shows that software reuse is the only means that can lead to unbounded productivity growth; practical considerations of size and cost of reusable components may reduce this to a finite bound

Happiness and the productivity of software engineers

Software companies and startups often follow the idea of flourishing happiness among developers. Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, company retreats, you name it. The rationale is that happy developers should be more productive and also retained. But is it the case that happy software engineers are more productive? Moreover, are perks the way to go to make developers happy? Are developers happy at all? What are the consequences of unhappiness among software engineers? These questions are important to ask both from the perspective of productivity and from the perspective of sustainable software development and well-being in the workplace. Managers, team leaders, as well as team members should be interested in these concerns. This chapter provides an overview of our studies on the happiness of software developers. You will learn why it is important to make software developers happy, how happy they really are, what makes them unhappy, and what is expected regarding happiness and productivity while developing software.Comment: 12 pages, 2 figures. To appear in Rethinking Productivity in Software Engineering, edited by Caitlin Sadowski and Thomas Zimmermann. arXiv admin note: text overlap with arXiv:1707.0043

Consequences of Unhappiness While Developing Software

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding the positive side of happiness -- positive emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that also studying the negative side -- unhappiness -- could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, and is mainly expressed in terms of development productivity and software quality. In this paper, we attempt to uncover the experienced consequences of unhappiness among software developers. Using qualitative data analysis of the responses given by 181 questionnaire participants, we identified 49 consequences of unhappiness while doing software development. We found detrimental consequences on developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data, will spawn new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.Comment: 6 pages. To be presented at the Second International Workshop on Emotion Awareness in Software Engineering, colocated with the 39th International Conference on Software Engineering (ICSE'17). Extended version of arXiv:1701.02952v2 [cs.SE

IT & C Projects Duration Assessment Based on Audit and Software Reengineering

This paper analyses the effect of applying the core elements of software engineering and reengineering, probabilistic simulations and system development auditing to software development projects. Our main focus is reducing software development project duration. Due to the fast changing economy, the need for efficiency and productivity is greater than ever. Optimal allocation of resources has proved to be the main element contributing to an increase in efficiency.Reengineering, audit, project duration assessment, Monte Carlo simulation

Agent-based simulation of open source evolution

We present an agent-based simulation model developed to study how size, complexity and effort relate to each other in the development of open source software (OSS). In the model, many developer agents generate, extend, and re-factor code modules independently and in parallel. This accords with empirical observations of OSS development. To our knowledge, this is the first model of OSS evolution that includes the complexity of software modules as a limiting factor in productivity, the fitness of the software to its requirements, and the motivation of developers. Validation of the model was done by comparing the simulated results against four measures of software evolution (system size, proportion of highly complex modules, level of complexity control work, and distribution of changes) for four large OSS systems. The simulated results resembled the observed data, except for system size: three of the OSS systems showed alternating patterns of super-linear and sub-linear growth, while the simulations produced only super-linear growth. However, the fidelity of the model for the other measures suggests that developer motivation and the limiting effect of complexity on productivity have a significant effect on the development of OSS systems and should be considered in any model of OSS development