The dimensions of software engineering success

Software engineering research and practice are hampered by the lack of a well-understood, top-level dependent variable. Recent initiatives on General Theory of Software Engineering suggest a multifaceted variable – Software Engineering Success. However, its exact dimensions are unknown. This paper investigates the dimensions (not causes) of software engineering success. An interdisciplinary sample of 191 design professionals (68 in the software industry) were interviewed concerning their perceptions of success. Non-software designers (e.g. architects) were included to increase the breadth of ideas and facilitate comparative analysis. Transcripts were subjected to supervised, semi-automated semantic content analysis, including a software developer vs. other professionals comparison. Findings suggest that participants view their work as time-constrained projects with explicit clients and other stakeholders. Success depends on stakeholder impacts – financial, social, physical and emotional – and is understood through feedback. Concern with meeting explicit requirements is peculiar to software engineering and design is not equated with aesthetics in many other fields. Software engineering success is a complex multifaceted variable, which cannot sufficiently be explained by traditional dimensions including user satisfaction, profitability or meeting requirements, budgets and schedules. A proto-theory of success is proposed, which models success as the net impact on a particular stakeholder at a particular time. Stakeholder impacts are driven by project efficiency, artifact quality and market performance. Success is not additive, e.g., ‘low’ success for clients does not average with ‘high’ success for developers to make ‘moderate’ success overall; rather, a project may be simultaneously successful and unsuccessful from different perspectives

Validity concerns in software engineering research

Empirical studies that use software repository artifacts have become popular in the last decade due to the ready avail-ability of open source project archives. In this paper, we survey empirical studies in the last three years of ICSE and FSE proceedings, and categorize these studies in terms of open source projects vs. proprietary source projects and the diversity of subject programs used in these studies. Our survey has shown that almost half (49%) of recent empirical studies used solely open source projects. Existing studies either draw general conclusions from these results or explic-itly disclaim any conclusions that can extend beyond specific subject software. We conclude that researchers in empirical software engi-neering must consider the external validity concerns that arise from using only several well-known open source soft-ware projects, and that discussion of data source selection is an important discussion topic in software engineering re-search. Furthermore, we propose a community research in-frastructure for software repository benchmarks and sharing the empirical analysis results, in order to address external validity concerns and to raise the bar for empirical software engineering research that analyzes software artifacts

Software engineering ethics

Software engineering ethics is reviewed. The following subject areas are covered: lack of a system viewpoint; arrogance of PC DOS software vendors; violation od upward compatibility; internet worm; internet worm revisited; student cheating and company hiring interviews; computing practitioners and the commodity market; new projects and old programming languages; schedule and budget; and recent public domain comments

Software engineering whispers: The effect of textual vs. graphical software design descriptions on software design communication

Context:\ua0Software\ua0engineering\ua0is a social and collaborative activity. Communicating and sharing knowledge between\ua0software\ua0developers requires much effort. Hence, the quality of\ua0communication\ua0plays an important role in influencing project success. To better understand the\ua0effect\ua0of\ua0communication\ua0on project success, more in-depth empirical studies investigating this phenomenon are needed. Objective: We investigate the\ua0effect\ua0of using a\ua0graphical\ua0versus\ua0textual\ua0design\ua0description\ua0on co-located\ua0software\ua0design\ua0communication. Method: Therefore, we conducted a family of experiments involving a mix of 240\ua0software\ua0engineering\ua0students from four universities. We examined how different\ua0design\ua0representations (i.e.,\ua0graphical\ua0vs.\ua0textual) affect the ability to Explain, Understand, Recall, and Actively Communicate knowledge. Results: We found that the\ua0graphical\ua0design\ua0description\ua0is better than the\ua0textual\ua0in promoting Active Discussion between developers and improving the Recall of\ua0design\ua0details. Furthermore, compared to its unaltered version, a well-organized and motivated\ua0textual\ua0design\ua0description–that is used for the same amount of time–enhances the recall of\ua0design\ua0details and increases the amount of active discussions at the cost of reducing the perceived quality of explaining

Towards Ecology Inspired Software Engineering

Ecosystems are complex and dynamic systems. Over billions of years, they have developed advanced capabilities to provide stable functions, despite changes in their environment. In this paper, we argue that the laws of organization and development of ecosystems provide a solid and rich source of inspiration to lay the foundations for novel software construction paradigms that provide stability as much as openness.Comment: No. RR-7952 (2012

A Process Algebra Software Engineering Environment

In previous work we described how the process algebra based language PSF can be used in software engineering, using the ToolBus, a coordination architecture also based on process algebra, as implementation model. In this article we summarize that work and describe the software development process more formally by presenting the tools we use in this process in a CASE setting, leading to the PSF-ToolBus software engineering environment. We generalize the refine step in this environment towards a process algebra based software engineering workbench of which several instances can be combined to form an environment