Enabling real-time feedback in software engineering

The existing software engineering seldom considers software usability, and human-computer interaction (HCI) techniques which can improve the software usability cannot guarantee development efficiency. Recently, more and more stakeholders and users begin to regard the usability as an important software requirement. In order to bring respective advantages of software engineering and HCI techniques into full play to improve software usability and development efficiency, the paper presents user model driven software development, which integrates HCI techniques into software development method by eliciting user model under the participation of user, HCI designer and software engineer. Applications show that the method can be effectively applied to small software development team, and can raise software usability and development efficiency.

Putting Requirements and Quality at the Core of Global Service Delivery: Current Efforts and Future Plans at Pace University

Software Engineering: A Methodical Approach (Second Edition) provides a comprehensive, but concise introduction to software engineering. It adopts a methodical approach to solving software engineering problems, proven over several years of teaching, with outstanding results. The book covers concepts, principles, design, construction, implementation, and management issues of software engineering. Each chapter is organized systematically into brief, reader-friendly sections, with itemization of the important points to be remembered. Diagrams and illustrations also sum up the salient points to enhance learning. Additionally, the book includes the author’s original methodologies that add clarity and creativity to the software engineering experience. New in the Second Edition are chapters on software engineering projects, management support systems, software engineering frameworks and patterns as a significant building block for the design and construction of contemporary software systems, and emerging software engineering frontiers. The text starts with an introduction of software engineering and the role of the software engineer. The following chapters examine in-depth software analysis, design, development, implementation, and management. Covering object-oriented methodologies and the principles of object-oriented information engineering, the book reinforces an object-oriented approach to the early phases of the software development life cycle. It covers various diagramming techniques and emphasizes object classification and object behavior. The text features comprehensive treatments of: Project management aids that are commonly used in software engineering An overview of the software design phase, including a discussion of the software design process, design strategies, architectural design, interface design, database design, and design and development standards User interface design Operations design Design considerations including system catalog, product documentation, user message management, design for real-time software, design for reuse, system security, and the agile effect Human resource management from a software engineering perspective Software economics Software implementation issues that range from operating environments to the marketing of software Software maintenance, legacy systems, and re-engineering This textbook can be used as a one-semester or two-semester course in software engineering, augmented with an appropriate CASE or RAD tool. It emphasizes a practical, methodical approach to software engineering, avoiding an overkill of theoretical calculations where possible. The primary objective is to help students gain a solid grasp of the activities in the software development life cycle to be confident about taking on new software engineering projects.

A recent trend in software engineering is the shift from a focus on laboratory-oriented software engineering to a more industry-oriented view of software engineering processes. This complements preceding ideas about software engineering in terms of organization and process-orientation. From the domain coverage point of view, many of the existing software engineering approaches have mainly concentrated on the technical aspects of software development. Important areas of software engineering, such as the technical and organizational infrastructures, have been left untouched. As software systems increase in scales, issues of complexity and professional practices become involved. Software development as an academic or laboratory activity, has to engage with software development as a key industrialized process. This expanded domain of software engineering exposes the limitations of existing methodologies that often address only individual subdomains. There is, therefore, a demand for an overarching approach that provide a basis for theoretical and practical infrastructures capable of accommodating the whole range of modern software engineering practices and requirements. One approach is provided by Process-Based Software Engineering (PBSE); part of the more general trend towards a focus on process. This paper provides a review of process techniques for software engineering and a high-level perspective on PBSE. Typical approaches and techniques for the establishment, assessment, improvement and benchmarking of software engineering process systems are introduced in this paper, and many are developed further in other contributions to this volume.

Free/Open Source Software (FOSS) development is not the same an Software Engineering (SE). Why this is so is unclear and open to various interpretations. Both address the challenges of developing large software systems, but the development processes, work practices, and project forms differ significantly and in intersting ways according to recent empirical studies. This paper reports on highlights from a workshop held in early 2010 on the future of research in FOSS, and how such research relates to or informs our understanding of FOSS and SE, collaborative software development work, software evolution, and new software ecosystems. FOSS and SE are complementary in many ways, yet different in others, so understanding these complements and differences can help advance the future of research in both FOSS and SE. Some of these complements and differences are identified in this paper.

Logicians may want to consider the following statements: Engineers use mathematics in their Software Engineers do not use mathematics in their What should we conclude from these axioms? would conclude that Software Engineers are not Engineers. Others would conclude that the first statement must be incorrect and should read, All Engineers except Software Engineers use mathematics in their work. They would argue that mathematics is irrelevant in software development. Still others would conclude that, Some of the people who now call themselves Software Engineers are not qualified to do so. Although much of the mathematics developed by Computer Scientists is not very practical, this talk will argue that mathematics can and should play a central role in software engineering. It will show how classical engineering concepts can be applied in software development. 3rd IEEE International Conference on Formal Engineering Methods (ICFEM'00)

The capability of an enterprise to innovate and promptly and effectively respond to change requests coming from both internal and external drivers has nowadays become a measure of the competitiveness of the enterprise in all business sectors. Innovation often implies modifying the enterprise business processes and, as a consequence, requires the evolution of the enterprise software systems. In this context, the workshop on Evolution of Software Systems in a Business Context (ESSBC), held in Budapest, Hungary, as part of the IEEE Software Technology and Engineering Practice workshop series (STEP 2005), aimed at discussing experiences and research outcomes and identifying research issues in supporting the evolution of enterprise software systems to reach innovation goals

App store analysis has become an important discipline in recent software engineering research. It empirically studies apps using information mined from their distribution platforms. Information provided by users, such as app reviews, are of high interest to developers. Commercial providers such as App Annie analyzing this information became an important source for companies developing and marketing mobile apps. In this paper, we perform an exploratory study, which analyzes over seven million reviews from the Apple AppStore regarding their emotional sentiment. Since recent research in this field used sentiments to detail and refine their results, we aim to gain deeper insights into the nature of sentiments in user reviews. In this study we try to evaluate whether or not the emotional sentiment can be an informative feature for software engineers, as well as pitfalls of its usage. We present our initial results and discuss how they can be interpreted from the software engineering perspective.

Depicting applications of several machine learning approaches in software systems development and deployment, this text provides analysis, characterization, and refinement of software engineering data in terms of machine learning methods.

For more than thirty years, it has been claimed that a way to improve software developers’ productivity and software quality is to focus on people and to provide incentives to make developers satisfied and happy. This claim has rarely been verified in software engineering research, which faces an additional challenge in comparison to more traditional engineering fields: software development is an intellectual activity and is dominated by often-neglected human factors (called human aspects in software engineering research). Among the many skills required for software development, developers must possess high analytical problem-solving skills and creativity for the software construction process. According to psychology research, affective states—emotions and moods—deeply influence the cognitive processing abilities and performance of workers, including creativity and analytical problem solving. Nonetheless, little research has investigated the correlation between the affective states, creativity, and analytical problem-solving performance of programmers. This article echoes the call to employ psychological measurements in software engineering research. We report a study with 42 participants to investigate the relationship between the affective states, creativity, and analytical problem-solving skills of software developers. The results offer support for the claim that happy developers are indeed better problem solvers in terms of their analytical abilities. The following contributions are made by this study: (1) providing a better understanding of the impact of affective states on the creativity and analytical problem-solving capacities of developers, (2) introducing and validating psychological measurements, theories, and concepts of affective states, creativity, and analytical-problem-solving skills in empirical software engineering, and (3) raising the need for studying the human factors of software engineering by employing a multidisciplinary viewpoint.

Background: During the period of one year, ING developed an approach for software analytics within an environment of a large number of software engineering teams working in a Continuous Delivery as a Service setting. Goal: Our objective is to examine what factors helped and hindered the implementation of software analytics in such an environment, in order to improve future software analytics activities. Method: We analyzed artifacts delivered by the software analytics project, and performed semi-structured interviews with 15 stakeholders. Results: We identified 16 factors that helped the implementation of software analytics, and 20 factors that hindered the project. Conclusions: Upfront defining and communicating the aims, standardization of data at an early stage, build efficient visualizations, and an empirical approach help companies to improve software analytics projects.

ExaFEL is an HPC-capable X-ray Free Electron Laser (XFEL) data analysis software suite for both Serial Femtosecond Crystallography (SFX) and Single Particle Imaging (SPI) developed in collaboration with the Linac Coherent Lightsource (LCLS), Lawrence Berkeley National Laboratory (LBNL) and Los Alamos National Laboratory. ExaFEL supports real-time data analysis via a cross-facility workflow spanning LCLS and HPC centers such as NERSC and OLCF. Our work therefore constitutes initial path-finding for the US Department of Energy’s (DOE) Integrated Research Infrastructure (IRI) program. We present the ExaFEL team’s 7 years of experience in developing real-time XFEL data analysis software for the DOE’s exascale supercomputers. We present our experiences and lessons learned with the Perlmutter and Frontier supercomputers. Furthermore we outline essential data center services (and the implications for institutional policy) required for real-time data analysis. Finally we summarize our software and performance engineering approaches and our experiences with NERSC’s Perlmutter and OLCF’s Frontier systems. This work is intended to be a practical blueprint for similar efforts in integrating exascale compute resources into other cross-facility workflows.

work of W. Edwards Deming has convinced industry that must first measure quality and then emphasise process to improve quality. In response to Deming's arguments and in light of perception that software industry is unable to produce quality products on schedule, and within budget, more software development organisations are now emphasising process measurement, monitoring, and assessment. This paper describes what is meant by software process and discusses an approach for its measurement and improvement. INTRODUCTION Unreliable software makes big news, from emergency services disasters to social security payment blunders. Improved software quality is essential to ensure reliable products and services, and gain customer satisfaction. While software development has existed for more than four decades, we failed so far to make as an industry and as an engineering discipline rather than craft. Developing reliable and usable software that is delivered on and within budget still represents difficult endeavour for many organisations. As role of software becomes increasingly critical for businesses as well as for human lives, problems caused by software products that are late, over budget, or that do not work, become magnified. If lives are lost or people inconvenienced due to incapable computer software, news media is there to make big stories. Organisations are realising that their fundamental problems is immaturity of their software process. Robert Lai (1993) proposes that process improvement is second maturity wave of software industry. He states that the first wave of software was developed using waterfall model in 1970's. Today we are Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 216 Software Management in midst of second wave maturity movement as we attempt to formally define development process and best ways to continuously improve it (Lai 1993). Taking lead in this area has been Watts Humphrey (Humphrey 1989, 1990, 1991), and Software Engineering Institute (SEI) at Carnegie Mellon University. SEI started in 1986 to develop process maturity framework to help organisations appraise maturity of their software process, and to provide guidance for organisations to improve their software process capability. A brief description of framework was released in September 1987, including maturity questionnaire. SEI evolved model and questionnaire into 5 -Level Capability Maturity Model (CMM) in 1991. In February 1993, released CMM version 1.1 (Paulk et al 1993). This paper discusses software process and describes capability maturity model (CMM). It also shows how CMM can be used as basis to measure maturity of software process of an organisation and plan its improvement. SOFTWARE QUALITY AND PROCESS IMPROVEMENT In his book Quality is Free Phil Crosby states that: Quality is free. It is not gift, is free. What cost money are unqualify of things all actions that involve not doing jobs right first time (Crosby 1980). If such statement is true for many disciplines, is particularly true for evidence is abundant in number of software products which exceeded their budget, were produced late, failed to satisfy user requirements, and are full of bugs. demand for improved software quality is increasing to ensure reliable products and services. benefits of improved quality comes in form of reduction in failure costs. For software projects failure costs include (DTI 1992): • costs of correcting defects, both before and after delivery • overruns against and budget • unnecessary high maintenance costs • indirect costs which users incur due to poor quality software link between process maturity and software quality is expressed in premise that The quality of software system is governed by quality of process used to develop and maintain it. One stumbling block to improving software quality seems to be that not enough attention is paid to overall development process itself. While software professionals typically devote their to developing, testing or documenting software products, no one has prime responsibility for improving software process. Experience has shown that if Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 Managing Systems 217 no one is working on software process, orderly improvement is unlikely. process certainly won't improve itself, rather, most likely, will deteriorate over time. Continuous improvement can occur only if process infrastructure is in place. Watts Humphrey argues in an early article published in Datamation, April 1989 that: Without work on process, there will be little or no progress in improving software. THE SOFTWARE PROCESS Adopting process view of software development represents revolutionary change in perspective. A process orientation to software development involves elements of structure, focus, measurement, ownership, skills, and supporting technology. In this section we investigate what is meant by software process. What Is Software Process According to Webster's dictionary, process is a system of operations in producing something .. series of actions, changes, or functions that achieve an end result. Chambers Concise Dictionary defines process as a series of actions or events .. sequence of operations or changes undergone. IEEE defines process as a sequence of steps performed for given purpose. In general business context, process is defined as a structured, measured set of activities designed to produce specified output for particular customer or market (Davenport 1993). These definitions put strong emphasis on HOW work is done, in contrast to product focus's emphasis on WHAT. Accordingly, process can be considered as a specific ordering of work activities across and place, with beginning, an end, and clearly identified inputs and outputs: structure for action. In this paper we will adopt following definitions quoted in (Humphrey 1990, Paulk et al 1993) are intended to encompass software throughout its life, which covers new development, enhancement, and repair. software process is The set of activities, methods, and practices used in production and evolution of software. software engineering process is The total set of software engineering activities needed to transform user's requirements into software. Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 218 Software Management People and Software Process Software development is still people-intensive activity. Talented people are most important element in any software organisation. Even if you get best people available, if they do not follow common process, if everyone wrote in different programming languages, used different conventions, or didn't co-ordinate their design and code changes with their peers, results will be chaos. Successful software organisations have learned that even best professionals need structured and disciplined environment in which to do cooperative work. Software organisations that do not establish such disciplines condemn their people to endless hours of repetitively solving technically trivial problems. obvious fact is that attracting best people is vital, but is also essential to support them with an effectively managed software process. Technology and Software Process Another myth is widespread belief that some technologically advanced tool or method will provide magic answer to software crisis. This is not only wrong, but is dangerous. Organisations which jumped on bandwagon of CASE tools, and ended up in failure and wasted and effort have learned their lesson hard way. Just ask yourself before introducing technology: What do I want to automate? In absence of defined, practised, and managed process, introducing automation can lead to increased chaos. There are several factors which limit effective use of software technology: an illdefined process, inconsistent process implementation, and poor process management. Software technology cannot be fully effective until these problems have been properly addressed. Need for Defined Process If no effort is made to define and enhance software development process across whole organisation, each software development project latches on to its own tools, methods, and practices with little guidance available on how to use them. This ad hoc approach will not be sufficient to tackle task of developing complex software systems. goal of software process management is to enable organisations to produce software that meets cost, schedules, and quality objectives. principles are same that underpins statistical process control-principles that have been successfully used in controlling scientific experiments and in high -volume manufacturing operations. Statistical concepts have been found to be just as applicable to software development as they are to production of manufactured goods such as motor cars. Applying such concepts will only be possible if there is defined and managed process. Software Process Models Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

Since the term “software engineering” was coined some 20+ years ago, [4] a number of definitions for both the practice and the practitioner, a “software engineer,” have been proposed. The definition from a recent report on undergraduate software engineering curricula [3] states:Software engineering entails the understanding and application of engineering principles, design skills, good management practice, computer science and mathematical formalism. …The Software Engineer must be able to estimate the cost and duration of the software development process, and to determine correctness and reliability and express them with a degree of precision meaningful to other engineers and informed clients. …In recent years, several advanced degree programs in “software engineering” have been instituted in the US and abroad. One example of this can be found at the SEI itself. Two of the goals of the SEI Education Program are to: (1) develop software engineering curriculum modules that identify, organize, and document the body of knowledge that could be taught in software engineering degree programs, and (2) design, develop, support, and maintain model curricula for undergraduate and graduate software engineering programs.The question remains, however, how much of this can be taught in a classroom setting or even in a design lab, and how much must be learned on the job or via some sort of apprentice program? What does Ada have to do with software engineering ? Can Ada exist without it? Can software engineering be done without Ada?There are those who believe the term “software engineering” is just plain wrong: [1]… I deeply resent the misuse of the word “engineering” in the compound term “software engineering.” Such misuse constitutes, in my opinion, a cheap, deceptive attempt to take advantage of the professional reputation and image developed by real engineers over a century or so … it constitutes theft of professional reputation.In 1986, I coordinated a similar panel for the ACM Computer Science Conference (CSC) [2]. The introduction from that session still holds true for this one, and is paraphrased and tuned below:Most universities prepare students for continued growth and development during a lifetime of employment, whether in an industrial or government setting. Since traditionally, such an education has implied better job opportunities, the university student believes that by studying computer science and/or software engineering, she2 will be assured of a good job at a reasonable salary performing interesting and challenging tasks.On the other hand, some universities prepare students for graduate education and research, placing a heavy emphasis on theory. From this perspective, the university student believes that upon completion of a computer science or software engineering degree, she will be able to choose where to pursue her research, at the university, industry, or government site of her choosing.Three years have passed; and I have found other group of articulate people to join us and present new and exciting viewpoints on the topic of software engineering, university education, and, of course Ada. Richard Fairley, who participated in that CSC panel, continues to represent the academic point of view; Marcia Finfer represents the industrial point of view; Garth Glynn also provides the industrial point of view with the interesting addition of evaluating graduate-level software engineering degree curricula; David Markus brings the perspective of the human resource issues; Lyn Plinta provides the view of the recent graduate dealing with veterans of the hacking era; and David Umphress represents the DoD interests.These panelists, bringing together a wealth of experience as educators, practitioners, and policy makers, provide insights from both the demand-side of software engineering and the supply-side, as they take a multi-faceted, multi-national look at industrial, academic, and government expectations of software engineering as it is taught and practiced today.

CONTEXT: Self-efficacy is a concept researched in various areas of knowledge that impacts various factors such as performance, satisfaction, and motivation. In Software Engineering, it has mainly been studied in the academic context, presenting results similar to other areas of knowledge. However, it is also important to understand its impact in the industrial context. OBJECTIVE: Therefore, this study aims to understand the impact on the software development context with a focus on understanding the behavioral signs of self-efficacy in software engineers and how self-efficacy can impact the work-day of software engineers. METHOD: A qualitative research was conducted using semi-structured questionnaires with 31 interviewees from a software development company located in Brazil. The interviewees participated in a Bootcamp and were later assigned to software development teams. Thematic analysis was used to analyze the data. RESULTS: In the perception of the interviewees, 21 signs were found that are related to people with high and low self-efficacy. These signs were divided into two dimensions: social and cognitive. Also, 18 situations were found that can lead to an increase or decrease of self-efficacy of software engineers. Finally, 12 factors were mentioned that can impact software development teams. CONCLUSION: This work evidences a set of behavioral signs that can help team leaders to better perceive the self-efficacy of their members. It also presents a set of situations that both leaders and individuals can use to improve their self-efficacy in the development context, and finally, factors that can be impacted by self-efficacy in the software development context are also presented. Finally, this work emphasizes the importance of understanding self-efficacy in the industrial context.