An Explainable Automated Model for Measuring Software Engineer Contribution

Component-based enterprise software engineering (CBESE) is a rapidly emerging trend in the software engineering area. In the CBESE approach, software systems are no longer built from scratch. Instead, reusable software components, built by in-house developers or commercial vendors, are used as the building blocks of new component-based enterprise software systems. The transition from traditional software engineering to component-based enterprise software engineering is often blocked or hindered by a variety of engineering, process-related, business-oriented, infrastructure, organizational and management issues. Resolving those issues requires a systematic approach to building a component-based and reuse-driven software engineering business. That is why software engineers need to acquire a new set of skills. This has introduced the need for a new course sequence that integrates component-based enterprise software engineering into the software and information engineering curriculum. A new major course in this sequence is focused on component-based and reuse-driven software engineering businesses. In this paper, we share our experience of developing such a new course. The course is intended to provide a solid foundation for integrating of research into education in the area of component-based enterprise software engineering. In this paper, we present the course's organization, its components, and our future plans for the course.

Communication among software and hardware engineers plays an important and significant role in successful completion of projects in the environments that hardware and software engineers cooperate to develop common products. In these environments communication is inevitable because both hardware and software engineers need to be aware of each other's main challenges and concerns with respect to the common project. The need for this communication is perceived to be even more in developing hardware-software interfaces and also in clarification of types and formats of the data that will be transferred between hardware and software components. In this paper, three different notations are proposed to help software and hardware engineers communicate each other in written and document-based way. By using these notations which are understandable by hardware and software engineers, the requirements relating to the data types and data formats will be depicted in uniform, detailed and accurate forms of documents. These notations that will be drawn by either hardware or software engineers in requirements phase, will describe the type and format of any interaction data at any size.

The Road Map to Software Engineering: A Standards-Based Guide by James Moore is recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society as a useful guide for software practitioners applying software engineering standards. Using software engineering standards in producing effective software This book provides a single overview of codified software engineering, the set of knowledge and best practices that apply to most projects most of the time. By laying out the accepted techniques, the text allows managers—as well as those paying the bill—to eliminate wasteful experimentation with unproved software practices while giving more attention to true innovations. Prepared in accordance with the Guide to the Software Engineering Body of Knowledge (SWEBOK), The Road Map to Software Engineering organizes relevant IEEE software and systems standards, along with standards from other sources, using two framewor s: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. Each framework reinforces the other, showing when other standards should be applied, as well as how they relate to one another. The Road Map to Software Engineering allows practitioners to quickly locate the standards pertinent to questions arising in real projects. Providing students with a comprehensive body of knowledge, the text also assists experienced professionals in finding and filling gaps in their understanding. Endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society, this book is a useful guide for both practitioners and students.

The Road Map to Software Engineering: A Standards-Based Guide by James Moore is recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society as a useful guide for software practitioners applying software engineering standards. Using software engineering standards in producing effective software This book provides a single overview of codified software engineering, the set of knowledge and best practices that apply to most projects most of the time. By laying out the accepted techniques, the text allows managers—as well as those paying the bill—to eliminate wasteful experimentation with unproved software practices while giving more attention to true innovations. Prepared in accordance with the Guide to the Software Engineering Body of Knowledge (SWEBOK), The Road Map to Software Engineering organizes relevant IEEE software and systems standards, along with standards from other sources, using two framewor s: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. Each framework reinforces the other, showing when other standards should be applied, as well as how they relate to one another. The Road Map to Software Engineering allows practitioners to quickly locate the standards pertinent to questions arising in real projects. Providing students with a comprehensive body of knowledge, the text also assists experienced professionals in finding and filling gaps in their understanding. Endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society, this book is a useful guide for both practitioners and students.

On the basis of an earlier contribution to the philosophy of computer science by Amnon Eden, this essay discusses to what extent Eden's `paradigms' of computer science can be transferred or applied to software engineering. This discussion implies an analysis of how software engineering and computer science are related to each other. The essay concludes that software engineering can neither be fully subsumed by computer science, nor vice versa. Consequently, also the philosophies of computer science and software engineering--though related to each other--are not identical branches of a general philosophy of science. This also implies that not all of Eden's earlier arguments can be directly mapped from the domain of computer science into the domain of software science. After the discussion of this main topic, the essay also points to some further problems and open issues for future studies in the philosophy of software science and engineering.

Welcome to SIGSOFT 2008 and the Sixteenth ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE-16). SIGSOFT 2008 provides many different opportunities for software engineering researchers and practitioners to interact. Four workshops, ranging in topics from specification and verification to collaborative development tools, provide an opportunity for in-depth discussion of particular areas. A doctoral symposium and a student research forum allow for lively exchange between experienced researchers and student participants. A symposium for new faculty and new researchers allows for sharing of experiences and the opportunity for those new to the field to gain advice from more experienced researchers. A symposium dedicated to software engineering educators aims to improve the recruitment, education and retention of students in software engineering. Also co-located with SIGOSFT 2008 is the 8th ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE), which provides an opportunity to explore how program analysis can help improve and extend the software tools available to developers. The main event at SIGSOFT 2008 is FSE, a leading conference for research in software engineering theory and practice. This year, FSE received 152 submissions from the global software engineering community. Each paper was reviewed by at least three members of the high-qualified technical program committee. The program committee met for one-and-a-half days to discuss the submissions in detail. Based on this discussion, the program committee selected 31 papers for presentation at the conference and publication in the conference proceedings. In addition to these papers, the conference proceedings contains abstracts from the keynote speakers and the SIGSOFT award winners that we are thrilled to have as part of the FSE-16 program.

This research investigates how feedback affects the motivation of software engineers and develops a model of feedback in software engineering. Motivation has been reported as having an impact on software engineers’ productivity, the quality of the software they produce, the overall success of a software development project, and on the retention of software engineers. Findings from the last 30 years of research investigating motivation in software engineering have identified several factors that influence the motivation of software engineers, but the impact of each individual factor remains unclear. Feedback was identified as a factor affecting motivation by several studies investigating motivation in software engineering. Several theories of motivation exist which identify factors affecting motivation and models of how motivation is affected. Feedback is identified as a factor in four theories of motivation. In 2008 a systematic literature review identified that the majority of previous studies investigating motivation in software engineering were not grounded in motivation theory. This suggests that the majority of previous research investigating motivation in software engineering has not adequately considered theories of motivation and their relevance in software engineering. This research explored the importance of feedback and the effect of the characteristics of feedback on the motivation of software engineers, collecting their thoughts, perceptions, reflections and reactions to feedback using a range of different research methods. The research began with a preliminary study investigating how software engineers perceived feedback, and if the characteristics they identified were comparable to those identified in other disciplines, notably clinical education. Further studies followed by investigating feedback in software engineering, the short-term impact of received feedback, and the effect of the ‘source’ and ‘medium’ feedback characteristics. The findings of the preliminary study were that software engineers identified characteristics of feedback comparable to those found in clinical education, which gave a basis for further studies. Software engineers reported that feedback was the most common method of tracking their individual progress in a software project. A diary study collecting instances of feedback reported by software engineers found that positive feedback typically increased the engineers’ job satisfaction, and that negative feedback typically led to a change in their behaviour. Building on the earlier findings of this research, a scenario study and an online survey combining both scenarios and questions investigated the effect of the source and medium feedback characteristics. The findings of the four studies identified that the feedback recipient’s values and perceptions of the feedback source, and any preference they had to the medium used to send the feedback, affected the impact of received feedback. The findings suggested that the feedback software engineers report as the most valuable is not the same as feedback reported as having the most impact. The findings suggest that in software engineering, theories of motivation do not adequately consider the impact of the characteristics of feedback and the effect of different forms of feedback on motivation. A model of feedback in software engineering was identified by combining the findings of the four empirical studies and relevant literature. The model captures how feedback is experienced by software engineers. Software engineers perceive the characteristics of the received feedback, which provides information that is used to make several assessments about the feedback. Each engineer’s individual value set influences their assessments, and their current state of mind / mood / emotions affect the engineer’s perceptions, assessments, and individual value set. The assessments of the feedback then result in the impact of the received feedback, which can have an effect on the engineer’s attitude, behaviour, motivation, performance, job satisfaction, and feelings.

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.

Past research has demonstrated that student misconceptions about degree programs can negatively affect enrolment and retention rates. Software engineering is a relatively new discipline that is distinct from computer science and other engineering specializations; however, it is still rapidly evolving and consequently there is potential for misconceptions about the new discipline to arise. A study was therefore undertaken to investigate the preconceptions of first-year students enrolled in various Bachelor of Engineering degrees. Students were asked to rank the importance of different skills and activities for software engineering, and to rate a variety of statements about software engineering using a Likert scale. First-year preconceptions were compared with the responses of fourth-year software engineering students who had completed a major industry-based project. The two groups of students had statistically significant differences of opinion with respect to many of the survey items. There were no statistically significant differences between the responses of first-year students from different engineering specializations. These findings are discussed in the context of recruiting and retaining software engineering students.

Our experience shows that a typical industrial project can enhance software engineering research and bring theories to life. The University of Kentucky (UK) is in the initial phase of developing a software engineering curriculum. The first course, a graduate-level survey of software engineering, strongly emphasized quality engineering. assisted by the UK clinic, the students undertook a project to develop a phenylalanine milligram tracker. It helps phenylketonuria (PKU) sufferers to monitor their diet as well as assists PKU researchers to collect data. The project was also used as an informal experimental study. The applied project approach to teaching software engineering appears to be successful thus far. The approach taught many important software and quality engineering principles to inexperienced graduate students in an accurately simulated industrial development environment. It resulted in the development of a framework for describing and evaluating such a real-world project, including evaluation of the notion of a user advocate. It also resulted in interesting experimental trends, though based on a very small sample. Specifically, estimation skills seem to improve over time and function point estimation may be more accurate than LOC estimation.

Software Testing, Verification and ReliabilityVolume 8, Issue 2 p. 105-106 Book ReviewFree Access Book Review: Software process improvement: practical guidelines for business success. SEI Series in Software Engineering. By Sami Zahran. Published by Addison-Wesley, Harlow, Essex, U.K., 1997. ISBN: 0-201-17782-X, 447 pages. Price: U.K. £29.95, Hard Cover. Colin Tully, Colin Tully De Montfort University, and Colin Tully Associates, Software and Systems Engineering Consultancy, 8 Manchester Close, Stevenage, Hertfordshire SG1 4TQ, U.K.Search for more papers by this author Colin Tully, Colin Tully De Montfort University, and Colin Tully Associates, Software and Systems Engineering Consultancy, 8 Manchester Close, Stevenage, Hertfordshire SG1 4TQ, U.K.Search for more papers by this author First published: 18 December 1998 https://doi.org/10.1002/(SICI)1099-1689(199806)8:2<105::AID-STVR160>3.0.CO;2-KAboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinked InRedditWechat No abstract is available for this article. Volume8, Issue2June 1998Pages 105-106 ReferencesRelatedInformation

There is a lot of momentum for software engineering to become a title act branch of engineering. A brochure from McMaster University (www.cas.mcmaster.ca/cas/undergraduate/SEbrochure.pdf, Fall 1999), reads, "At McMaster we have taken the position that software engineering is a branch of engineering and have applied well established principles of engineering education in this new specialty." And, the Texas Board of Professional Engineers is certifying software engineers as title act engineers, today. If other states follow then software engineering will become a title act branch of engineering by fiat.While I agree that software engineering resembles traditional engineering in many ways, I also believe that software engineering is a whole new kind of engineering that is equal to, parallel to, and independent of traditional engineering. I believe that if software engineers want to be licensed, they should recognize their unique reality and become licensed in a way that reflects this reality. Software engineers should be professionalized on their own terms, with their own regulatory structure. Software engineers should create a whole new kind of engineering, and not just follow the path trodden by traditional engineers.In the first section, I argue that software engineering is a real profession that stands on its own and that its culture differs substantially from that of traditional engineering. Software engineering is big: it counts nearly as many practitioners as traditional engineering; diverse: it has many areas of specialized practice; and enduring: it has grown steadily for more than fifty years. Every facet of software engineering, from technology to attitude to origins, differs from traditional engineering, which profoundly affects the culture of software engineering. Software engineering is not a branch of traditional engineering.In the second section, I argue that all-of-software-engineering-combined should resemble all-of-traditional-engineering-combined. Four kinds of traditional engineering regulation are practiced today that software engineering can emulate: unregulated, title-act, practice-act, and all-of-engineering-combined. Of these four kinds, title-act and all-of-engineering-combined are the most likely outcomes. There is a lot of momentum to regulate software engineering as a title-act branch of engineering. However, regulating software engineering like all-of-engineering-combined will give software engineers more control over their destiny, let them define their own identity and culture, wield their own power, and set their own curriculum and immigration policy.

Decision making pervades software and systems engineering. Intertemporal decisions involve trade-offs among outcomes at different points in time. They play a central role in systems design, as recognised since the inception of the software engineering (SE) field. They are also crucial for the sustainability of design decisions. However, temporal decision making is not adequately understood in SE. The field of Judgement and Decision Making (JDM) offers important empirical findings and research methods that could be utilised. This article establishes a baseline for studying how software professionals handle intertemporal choices. It examines how temporal distance affects choices in an example scenario, explores in what areas of software development such decisions can be found, and examines how systems design decisions can be characterised and studied as intertemporal. We developed a method to study intertemporal choice in SE, based on an initial set of psychological theory grounded in JDM. We instantiated the method in a study to elicit responses to an intertemporal choice task followed by a Cognitive Task Analysis (CTA) interview. We found that study participants overall tended to discount future outcomes, but individual participants varied wildly in how they valued present vs. future outcomes. They indicated several locations in which intertemporal choices occur in everyday software development. Based on these findings, and by reconciling our initial theory with existing JDM theory and results, we further developed and refined our theory and study method into a framework for studying intertemporal decision making in SE. To obtain a basis for more sustainable software systems design decisions, SE research should adopt a more comprehensive, detailed, and empirically consistent way of understanding and studying intertemporal choices. We provide suggestions for how future research could achieve practical methods that address essential characteristics of real-life systems design decisions.

Motivation in Software Engineering: A systematic literature review

This chapter presents a methodology for combining software and data engineering life cycles in large software projects. Software and data engineering use multiple stages to form a life cycle for the creation of a system. Large projects often have elements of both software and data engineering. These are usually kept independent from each other as the development approaches are quite divergent; software engineering tends to be top-down, prescriptive and rigid, while data engineering tends to be bottom-up, descriptive and fluid. The methodology presented in this chapter defines a system for sharing and reuse of artefacts between software and data engineering development processes, in spite of the differences in development philosophies. The methodology helps to identify dependencies to support project planning, reduces effort by reuse and collaboration and increases quality by application of best practices. The central aspect of the methodology is a table which is used to define the synchronisation points between the two development domains, where collaboration between the separate life cycles can occur. Developers engaged in either life cycle can use a synchronisation table created for the project to send and receive shared artefacts between life cycles. This work is informed by the development and management of the ALIGNED project, a large, multi-partner, interdisciplinary project that involves both software and data engineering.