What is software development productivity, anyway? (Keynote)

Methods for Monitoring Productivity in Applicative Software Development

In this paper, we identify a set of factors that may be used to forecast software productivity and software development time. Software productivity was measured in function points per person hours, and software development time was measured in number of elapsed days. Using field data on over 130 field software projects from various industries, we empirically test the impact of team size, integrated computer aided software engineering (ICASE) tools, software development type, software development platform, and programming language type on the software development productivity and development time. Our results indicate that team size, software development type, software development platform, and programming language type significantly impact software development productivity. However, only team size significantly impacts software development time. Our results indicate that effective management of software development teams, and using different management strategies for different software development type environments may improve software development productivity.

Uptake of HCI and usability engineering by software development organisations can be terminally impeded by lack of appreciation of the benefits of HCI activities. However, descriptions of HCI offerings in terms of activities (e.g. task analysis, user mapping, allocation of function, interaction design) and methods (e.g. user profiling, prototyping, GOMS modelling) do not convey to product managers a readily comprehensible conception of the value of such offerings. Similarly, descriptions of HCI activities and methods give little indication of how these are to be associated and managed with reference to stages and deliverables in a software development life cycle. This lack of clear association between usability engineering and software engineering contributes to the marginalisation of usability related activities. Even when investment is made in usability resources its eventual pay off can be minimal, with resulting disillusionment on both sides. Specification of usability deliverables can provide a solid basis for a manageable usability perspective on the development of software products. The article identifies usability deliverables and describes their content and relation to deliverables in a software design and development process. More general implications for an approach to the specification of quality processes for the creation of interactive software products are discussed.

Software development productivity, code quality, and knowledge sharing have all increased dramatically with the use of AI code assistants like GitHub Copilot. These technologies provide real-time suggestions, expedite workflows, and speed up prototyping by utilising massive language models that have been trained on extensive code repositories. However, serious questions about software security, developer dependency, and ethical ramifications are brought up by their increasing use. The advantages and disadvantages of AI code helpers for safe software development are discussed in this study. It highlights how crucial human oversight, frequent security audits, ongoing model upgrades, and conformity to DevSecOps and OWASP guidelines are. In the end, software integrity cannot be jeopardised by including AI into development processes. In an increasingly automated development context, strategic implementation is crucial to maximising AI's benefits while protecting against new risks.

The ultimate aim of software engineering methods and tools is to reduce risks associated with the development of software products. Accepted risk management procedures recognize that software development is inherently risky, however fail to take into account the changing nature of both software products and the organizations undertaking their development. SE research has traditionally focused on the needs of very large corporations undertaking equally mammoth and complex development projects, thus most tools and methods are predicated on this model. Yet most software development is undertaken by small to medium enterprises. Consequently, these development efforts are either undertaken with little or no adherence to any SE standard process or by attempting to tailor processes intended for larger organizations. Neither of these alternatives is ideal, with both introducing new elements of risk. The rise of the Internet as a platform for commercial applications has partly driven this move away from monolithic software development and has also contributed to the proliferation of software products built using COTS components. Clearly there is a risk involved in the use of components not developed specifically for a particular application while Internet applications introduce an. entirely new set of possible risks. These newer risk factors directly affect the quality of the software product and the paper discusses these factors in detail, showing how they contribute to making software development today an even riskier proposition than previously.

Adopting key lessons from agile manufacturing to agile software product development—A comparative study

Typical design flows supporting the software development for multiprocessor systems are based on a board support package and high-level programming interfaces. These software design flows fail to support critical design activities, such as design space exploration or software synthesis. One can observe, however, that design flows based on a formal model of computation can overcome these limitations. In this article, we analyze the major challenges in multiprocessor software development and present a taxonomy of software design flows based on this analysis. Afterwards, we focus on design flows based on the Kahn process network (KPN) model of computation and elaborate on corresponding design automation techniques. We argue that the productivity of software developers and the quality of designs could be considerably increased by making use of these techniques.

This paper reports on a quantitative study, which examines the link between software characteristics, sought after consequences and personal values in software evaluation, whilst investigating the stakeholders' understanding of software quality. The study involved a survey of 403 subjects, which were then analyzed quantitatively with bi-variate analysis, and multivariate analysis of variance. The research argues that trade-offs in software development projects are often experienced in software development because of conflicts. These conflicts involve schedules, priorities and are very much caused by the different stakeholder views of quality, different desired consequences sought by the different stakeholders and more importantly influenced by the desired values of the different stakeholders. The research finds that different classes of stakeholders have different views of software quality. The research also finds that certain values sought by the stakeholder influences their sought after consequences required in the developed software product. However, it is not just any values that affect the stakeholder, but rather, it is the values affected by the evaluated software, which influences the selection of characteristics and sought after consequences. Values, which are important, but are not affected by software use, do not influence the stakeholder. As such, these results help us gain a better understanding of what types of values influence the choice of characteristics in software evaluation, and the desired consequences in a software product, and why conflicts exist during software development life-cycle. The results provide a number of important insights and suggest several conclusions. The study showed (1) that stakeholders differ in their priorities in the sought after consequences of the software being developed; (2) that the desired values, which are perceived to be affected by the software differ between stakeholders and influence the choice of characteristic and consequence; (3) that the consequence, value relationship as described in the Software Evaluation Framework can be valuable to understand the conflicts and trade-offs fond in software development.

Much of contemporary scienti c discussion regarding factors that in uence software de- velopment productivity is undertaken in various domains where there is an insu cient empirical basis for exploring socio-technical factors of productivity that are speci c to a software development organization. The purpose of the study is to characterize the mul- tidimensional nature of software development productivity and its social aspects as a set of latent constructs (i.e. variables that are not directly observed) for a medium-sized software company. To this end, we designed an exploratory in-depth eld study based on the hypothesized productivity constructs, which were modeled by a set of factors identi ed from literature reviews, and later re ned by industrial focus groups. In or- der to demonstrate the applicability of our approach, we conducted con rmatory factor analysis with the data attained from a questionnaire with 216 participants. To investigate factors of in uence further, we analyzed the impact of selected team- based variables over the latent constructs of productivity. Taken together, our ndings con rm that such an approach can be used to explore the quanti able in uence of socio- technical factors that would a ect productivity of a particular software development organization. Ultimately, the resulting model provides guidance to explore the compara- tive importance of a set of rm-speci c factors that may help to improve the productivity of the organization.

Unless the business model that governs software production adjusts to new technology, it is unlikely that an investment in the technology will result in real productivity benefits. Commercial development always takes place in the context of a business model, and in that context an understanding of how business constraints influence commercial software development is imperative. As software markets become more competitive and business pressures shorten software development cycles, improved software development productivity continues to be a major concern in the software industry. Many believe that new software technology, such as object-oriented development, provides a breakthrough solution to this problem. Unfortunately, there is little quantitative evidence for this belief. In this paper we explore the relationship between the business model and the productivity that a software development methodology can achieve in a commercial environment under that model. We first examine empirical data from several commercial products developed using object-oriented methods. The results indicate that object-oriented development may not perform any better than "procedural" development in environments that lack incentives for early completion of intermediate project tasks. We then model and simulate the impact of the software task-completion incentives and deadlines on the productivity that might be expected from a technology with high-performance potential. We show how and why some common business practices might lower project productivity and project completion probability. We also discuss to what extent poor software process control and (im)maturity of the technology compounds the problem.

Computer‐aided software engineering (CASE) is both a field of study and a marketplace. As a field of study, it is the collection of research and development over many years in software development management, methods, environments, and software tools. In general terms, CASE is the industrialization of software engineering techniques and computer technology to improve and automate the practice of information systems development. It is an integration technology that incorporates software development techniques, tools, and approaches into common and consistent frameworks. CASE draws on technologies from computer‐aided design, software engineering, operating systems, database, networking, and many other computer disciplines. Thus CASE is not principally a field of new invention. Rather, it is a field of application, integration, and synthesis. As a marketplace, CASE represents a diverse set of products and services for software development and systems integration. The acronym CASE is used as an umbrella for a wide variety of claims regarding software tools and software development productivity. Definitions of CASE are given. CASE evironments, automation of analusis, computer‐supported collaboration, apportunities for quality engineering, maintenance and reengineering are discussed.

A reuse base for real-time software specifications

Development of software products can often result in generation of Software Development Waste (SDW). For example, developers may possibly need to rework implementations that cater to ambiguous feature stories. COVID-19 pandemic has influenced the way software development teams operate worldwide. We studied the impact of pandemic enforced work-from-home situation (PWS) on generation of SDW. As a part of a multi-year study, we surveyed 615 participants and interviewed 31 from the software industry across eight countries specializing in various domains. We observed a rise in SDWs, and were able to identify new type of SDW, and other wastes that could be reclassified into existing types of wastes.

One of the most important concerns in software industry is the development of software products with the optimal use of resources. Therefore, a software development organization needs to be efficient and have software engineering practices that allow it to be efficient according to its particular needs and business goals. A feasible way to achieve this is by implementing software process improvements that allow the organization the selection and the implementation of those best practices that help it to improve its processes and to become more efficient. This research proposes a method to lighten software processes that enable organizations, especially SMEs, to assess the activities of their software development processes, so that the processes are optimized based on practices that add more value to them, and therefore lead them to be more efficient.

Software reuse is used to aid the software development process which in recent times can improve there quality and productivity of software development. There are a lot of free clinical software without any cost that provides better use to chance for designers to create medical tools at an efficient rate and in a quicker way. Therefore, the minor research work on shareware health care software faces some different situations for designing environments in clinical app growth. This research actually aims to support healthcare designers' great understanding of shareware public domain software by conducting detailed research on shareware public domain software monitored on GitHub repository. The main aim is that we make a specific method that gathers relevant data and then takes some action on the given GitHub data. After the different research in-depth, with its different ways like numeric research, theory-based research, and econometric research, that was handled to gain the main or actual theme and its different properties of open-source clinical software. Around 14,971 projects/software are paid but on the other hand, 12,919 software are open source, unpaid, or free of cost, which helps to make clinical software at a minimum cost and make clinical software more effective. The conclusion may handle different members, mainly beginners, in handling shareware and public domain software.