The impacts of quality and productivity perceptions on the use of software process improvement innovations

Numerous software process improvement (SPI) innovations have been proposed to improve software development productivity and system quality; however, their diffusion in practice has been disappointing. This research investigates the adoption of the Personal Software Process on industrial software projects. Quantitative and qualitative analyses reveal that perceived increases in software quality and development productivity, project management benefits, and innovation fit to development tasks, enhance the usefulness of the innovation to developers. Results underscore the need to enrich current technology acceptance models with these constructs, and serve to encourage project managers to adopt formal SPI methods if developers perceive the methods will have positive impacts on their productivity and system quality.     

Perceived barriers to effective knowledge sharing in agile software teams

While the literature offers several frameworks that explain barriers to knowledge sharing within software development teams, little is known about differences in how team members perceive these barriers. Based on an in‐depth multi‐case study of four software projects, we investigate how project managers, developers, testers and user representatives think about barriers to effective knowledge sharing in agile development. Adapting comparative causal mapping, we constructed causal maps for each of the four roles and identified overlap and divergence in map constructs and causal linkages. The results indicate that despite certain similarities, the four roles differ in how they perceive and emphasize knowledge‐sharing barriers. The project managers put primary emphasis on project setting barriers, while the primary concern of developers, testers and user representatives were project communication, project organization and team capabilities barriers, respectively. Integrating the four causal maps and the agile literature, we propose a conceptual framework with seven types of knowledge‐sharing barriers and 37 specific barriers. We argue that to bridge communication gaps and create shared understanding in software teams, it is critical to take the revealed concerns of different roles into account. We conclude by discussing our findings in relation to knowledge sharing in agile teams and software teams more generally.     

Perceptions of system development failures

According to the expectation failure theory, information system failures can occur during development or during system use and may be viewed differently by various stakeholder groups. This premise is examined via a survey of system developers and system users about their perception of frequency of system development problems. The data indicates that users and developers of information systems perceive certain problems at different levels of occurrence.     

Understanding the gap between software process practices and actual practice in very small companies

This paper reports on a grounded theory to study into software developers’ use of software development processes in actual practice in the specific context of very small companies. This study was conducted in three very small software product companies located in Ecuador. The data collection was based on semi-structured qualitative interviews with software project managers, focus group with software developers and was supplemented by the literature and document studies. We interviewed two types of participants (managers and developers), so as to ensure that we elicited a holistic perspective of how they approached the software development process in actual practice. The goal was to study what practices are actually used and their opinion and attitude toward the potential adopting of an international standard (ISO/IEC 29110) specifically designed for very small companies. With the collected data, we performed an analysis utilizing grounded theory coding techniques, as this methodology promotes the focus on uncovering the real concerns of the participants. This study highlighted three areas of concern: customer, software product and development tasks coordination and tracking. The findings in this study give an insight toward the work products as they relate to software development process practices in very small companies and the important factors that must be considered to assist project success.     

Process integration in CASE environments

Research in CASE environments has focused on two kinds of integration: tool and object. A higher level of integration, process integration, which represents development activities explicitly in a software process model to guide and coordinate development and to integrate tools and objects, is proposed. Process integration uses software process models (SPMs) a process driver, a tool set, and interfaces for both developers and managers to form the backbone of a process-driven CASE environment. The developer's interface, a working environment that lets developers enact an SPM, and the manager's interface which gives managers and analysts the tools to define, monitor, and control the SPMs that developers are working on concurrently are discussed. The Softman environment experiment, an implementation of process-driven CASE environments with existing CASE environments, is reviewed     

Model for measuring quality of software in DVRS using the gap concept and fuzzy schemes with GA

A model of software quality is proposed to measure the quality of the software in a digital video recorder system (DVRS) during its development stage. The characteristics and metrics of this model are adopted from ISO/IEC 9126 and 14598. The model incorporates a λ-fuzzy measure, a genetic algorithm and a hierarchical Choquet integral. It is based on the gap concept between perceive performance by the developers and satisfaction by the end-users, acquirers and evaluators of third parties in software development stage. A checklist about of the software quality is used to reduce the gap between the quality of the DVRS software quality as assessed by the developers and that as assessed by the end-users, acquirers and the evaluators of third parties.     

How agile software development methods reduce work exhaustion: Insights on role perceptions and organizational skills

Agile methods are widely used in the software industry as a way to more rapidly develop and deliver new software. They define iterative work processes, advocate self‐organization and openness for change, and prescribe how software developers interact with each other and external stakeholders. Despite their popularity, it is unclear how agile methods influence work exhaustion in software developers and how developer skills play into this effect. On the one hand, agile methods may reduce software developers' work exhaustion by levelling out their workload across the entire duration of a project. On the other hand, agile methods exert a high level of pressure on software developers to continuously deliver working software, create many intensive social interactions, and to frequently adapt to changes. In light of these effects, prior research could not explain why some software developers become less exhausted from using agile methods, whereas others perceive the exact opposite. Based on the job demand‐control model, we develop a theoretical model connecting agile method use to individual developer skills and to two established determinants of employee exhaustion: role conflict and role ambiguity. We tested our research model in a field study among 1894 software developers in 217 project teams that used agile methods. The random coefficient modelling results show that agile method use facilitates the achievement of clear and unambiguous role perceptions and thereby reduces work exhaustion in developers, particularly if developers possess the organizational skills to effectively interact with others in their organization. We highlight implications for theory on the individual‐level effects of software development methods and provide practical insights for software companies.     

Source code size estimation approaches for object-oriented systems from UML class diagrams: A comparative study

BackgroundSource code size in terms of SLOC (source lines of code) is the input of many parametric software effort estimation models. However, it is unavailable at the early phase of software development.ObjectiveWe investigate the accuracy of early SLOC estimation approaches for an object-oriented system using the information collected from its UML class diagram available at the early software development phase.MethodWe use different modeling techniques to build the prediction models for investigating the accuracy of six types of metrics to estimate SLOC. The used techniques include linear models, non-linear models, rule/tree-based models, and instance-based models. The investigated metrics are class diagram metrics, predictive object points, object-oriented project size metric, fast&&serious class points, objective class points, and object-oriented function points.ResultsBased on 100 open-source Java systems, we find that the prediction model built using object-oriented project size metric and ordinary least square regression with a logarithmic transformation achieves the highest accuracy (mean MMRE = 0.19 and mean Pred(25) = 0.74).ConclusionWe should use object-oriented project size metric and ordinary least square regression with a logarithmic transformation to build a simple, accurate, and comprehensible SLOC estimation model.     

No quality without equality

Quality control mechanisms play an important role in improving software quality. However, quality improvement requires us to customize and calibrate these mechanisms to particular development environments. To do this, managers must understand how quality mechanisms affect developers and, in turn, how developers and their perspectives affect quality mechanisms. Otherwise, calibration and improvement are uncontrolled. Managers must recognize that software developers do not form a homogeneous group. Different developers may have different thoughts about and reactions to the use of formal quality mechanisms, which makes optimizing quality control a tricky business. Indeed, developers may have significantly different views of what quality itself means. To implement effective quality-control tools and practices, managers must understand these different developer attitudes. When differentiating types of developers, we often classify them in terms of their experience with different domains, languages, tools, and practices. My research reveals that we may want to look also at the differences in attitudes between men and women     

Explaining software developer acceptance of methodologies: a comparison of five theoretical models

Many organizations attempt to deploy methodologies intended to improve software development processes. However, resistance by individual software developers against using such methodologies often obstructs their successful deployment. To better explain why individual developers accept or resist methodologies, five theoretical models of individual intentions to accept information technology tools were examined. In a field study of 128 developers in a large organization that implemented a methodology, each model explained significant variance in developers' intentions to use the methodology. Similar to findings from the tool adoption context, we found that, if a methodology is not regarded as useful by developers, its prospects for successful deployment may be severely undermined. In contrast to the typical pattern of findings in a tool context, however, we found that methodology adoption intentions are driven by: 1) the presence of an organizational mandate to use the methodology, 2) the compatibility of the methodology with how developers perform their work, and 3) the opinions of developers' coworkers and supervisors toward using the methodology. Collectively, these results provide surprising new insights into why software developers accept or resist methodologies and suggest what software engineering managers might do to overcome developer resistance.     

Tools fair: untangling the web with Web and client/serverdevelopment tools

This article concentrates on tools for developing applications for the Internet and for client server distributed environments. These tools help serious software developers build applications that support company missions, goals, and objectives. The article also includes a testing and a miscellaneous category to describe a few tools that may interest software development managers     

Toward a reference process for developing wireless Internet services

Wireless Internet services such as mobile Web applications promise an enormous market potential. The field is characterized by extreme time-to-market pressure and insufficient knowledge about development procedures and technical constraints. This results in insufficient guidance for project managers and software developers on selecting appropriate development processes, techniques, methods, and tools. In addition, there is an enormous lack of knowledge about the effects (such as effort consumption, defect injection) of such technologies that hinders the transfer of innovative technologies into practice. This article describes an initial reference process by summarizing essential technologies for the development of wireless Internet services and experience with these technologies on the levels of life cycle processes, engineering processes, and managerial processes. The reference process is based on a comprehensive literature survey and the execution of development projects for wireless Internet services. The goal of the article is to provide domain-specific guidance for project managers and software developers with accompanying lessons learned from the past.     

How software engineers use documentation: the state of the practice

Software engineering is a human task, and as such we must study what software engineers do and think. Understanding the normative practice of software engineering is the first step toward developing realistic solutions to better facilitate the engineering process. We conducted three studies using several data-gathering approaches to elucidate the patterns by which software engineers (SEs) use and update documentation. Our objective is to more accurately comprehend and model documentation use, usefulness, and maintenance, thus enabling better decision making and tool design by developers and project managers. Our results confirm the widely held belief that SEs typically do not update documentation as timely or completely as software process personnel and managers advocate. However, the results also reveal that out-of-date software documentation remains useful in many circumstances.     

A conflict between the use of estimating and planning tools in the management of information systems

This paper argues that there is a difference between how software development project managers perceive the task of estimating project costs and duration and the way in which commercially available estimating tools are designed to be used. A model of the early estimating/planning stages of a project (the EEPS model) is presented which suggests estimation could be first carried out either before or during the first detailed planning stage. A survey was carrried out which confirmed that project managers typically perceive the ‘true’ process of estimation as being part of planning. This result may explain why estimating tools are not widely used: planning tools are being used instead. By making a temporal distinction between the points at which project information first becomes available, however, it can also be seen that even planning must be driven by some assessment of the size and complexity of a project. At this point only estimating tools are available to provide such estimates. The conclusion seems to be that estimating tools do have a role to play in project management, but they must be explicitly task-based in order to fit the way in which project managers currently perceive estimation.     

Strengths and barriers behind the successful agile deployment—insights from the three software intensive companies in Finland

The number of success stories being reported concerning agile software development has led to an increase in interest among industries and research communities. The purpose of this paper is to identify strengths and barriers for ‘successful agile deployment’ in the software companies. This knowledge can benefit software companies planning their current strategy for agile deployment. Analysis of 57 developers, architects, project managers, customers, quality managers, and line and product managers in three case companies identifies 71 strengths and 169 barriers of agile deployment. The analysis revealed the importance of management providing the necessary goals and support for agile development. It also indicated the significance of defining a tailored process model and giving developers the freedom to improve their own agile development process continuously during agile deployment. The identified barriers, strengths and recommendations can be used as a checklist for planning and/or monitoring the effectiveness of agile deployment in software companies. By identifying the barriers and strengths of agile deployment, the paper deepens understanding of this highly relevant but relatively under-researched phenomenon and contributes to the literature on agile deployment and software process improvement.     

Teaching secure programming

Computer users, managers, and developers agree that we need software and systems that are "more secure". Such efforts require support from both the education and training communities to improve software assurance -particularly in writing secure code.     

支持多工具协同的流程管理系统的设计与实现

软件开发流程中越来越依赖各种计算机辅助软件（CAS）。在使用多种工具的情况下,会遇到开发流程不可定制、流程数据不一致和流程管理效率低等问题。针对这些问题提出了一个支持多工具协同工作的软件开发过程管理系统。通过分析软件开发过程,研究支持快速迭代、偏向流程管理的软件工程开发模式,结合工作流思想设计分层架构的软件开发过程管理系统。该系统经过严格的测试用例检测,在设计的576个测试用例下通过率达到85%,能够完成工具协同的大部分需求,包括流程可定义、保持数据一致和开发流程管理。该系统在7个软件开发组,共约200人的规模下推广试用。根据管理组、开发组和测试组的反馈结果,该系统比传统方式节省了每周例会的时间,方便了开发任务的管理,从而提高了开发效率。     

Reuse-Conducive Development Environments

Despite its well-recognized benefits, software reuse has not met its expected success due to technical, cognitive, and social difficulties. We have systematically analyzed the reuse problem (especially the cognitive and social difficulties faced by software developers who reuse) from a multidimensional perspective, drawing on our long-term research on information retrieval, human-computer interaction, and knowledge-based systems. Based on this analysis, we propose the concept of reuse-conducive development environments, which encourage and enable software developers to reuse through the smooth integration of reuse repository systems and development environments. We have designed, implemented, and evaluated CodeBroker—a reuse-conducive development environment—that autonomously locates and delivers task-relevant and personalized components into the current software development environment. Empirical evaluations of CodeBroker have shown that the system is effective in promoting reuse by enabling software developers to reuse components unknown to them, reducing the difficulties in locating components, and augmenting the programming capability of software developers.     

How experienced project managers assess risk

Software development projects, given their diverse and abstract nature, offer unique challenges and risks. Although a substantial body of literature has been written to address project risk management, my experience in the field led me to question whether this literature accurately mirrors the concerns of real-world project managers. To confirm my suspicions, I surveyed 14 experienced application systems developers, all located in Ireland. All survey participants manage custom-built, software-intensive application development projects that originate from external clients. The survey focused on three major areas: (1) Which characteristics of the customer, the application, and so on, do experienced software project managers consider important when planning new development projects for new, external clients? (2) How do these characteristics relate to accepted software project risk drivers? (3) Do most project managers characterize new projects in generally the same way, or do different project managers use different perceptual lenses when viewing new projects? This survey of a homogenous group of project managers revealed a surprising diversity of risk management concerns     

A validation of the end-user computing satisfaction instrument in Taiwan

This article focuses on the psychometric stability of the end-user computing satisfaction (EUCS) instrument by Doll and Torkzadeh when applied to Taiwanese end-users of typical business software applications. Using a survey of 342 users, this research provides evidence that the instrument is a valid and reliable measure in Taiwanese applications. Given this evidence, managers and software product developers can confidently apply the instrument in the investigation of competing tools, features, and technologies in Taiwan.