A reusable, academic-strength, metrics-based software engineering process for capstone courses and projects

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

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

Welcome to the International Conference on Software and Systems Process (ICSSP) held in Zurich, Switzerland, on June 2nd and 3rd, 2012. Having grown from a Software Process Workshop in 2005 to the International Conference on Software Process (ICSP) in 2007, and finally to the International Conference on Software and Systems Process (ICSSP) in 2011, this conference series has established its place in the software engineering community as a respected conference focusing on research and practice related to software and systems development process. Software and software systems development use processes as one major means for achieving and ensuring the quality of the final product. This leads to specific challenges regarding software processes such as simplicity, adaptability, standard conformance, the coordination of multiple domains and lifecycles, etc. Processes from other domains (e.g., health care, manufacturing, business, aerospace, automotive systems, and others) face similar challenges. Yet, they share interesting similarities with and differences to software processes. The question is: How can we in the software domain learn from other domains to meet our software process engineering challenges? The ICSSP conferences hence connect the traditional software and systems process community with outside views and insights, broadening its scope of software development processes to system development and explicitly including processes of other domains such as health care, business, and manufacturing. By sharing process development theories and practices from such domains, ICSSP 2012 is investigating novel solutions to today's process challenges. Correspondingly, the main theme of ICSSP 2012 is Beyond Software and Software Systems Processes, signaling our goal of learning from domains other than the traditional software process community.

Software engineers have always been experimenting with various models in an endeavor to improve upon software processes. Recently, a new area of software process improvement through experience management has got attention of the software engineering community. Software developers are experimenting with experience management to improve software process. This chapter explores the role of experience management in mitigating the effects of software crisis and investigates the current state of EM in Indian software engineering environment. The chapter discusses the need and integration of knowledge and experience management practices in software engineering environments. The chapter begins with the discussion of the ills of software engineering, classically referred to as “software crisis,” like late delivery of the systems, ill-functionality, and cost overruns, and justifies how managing the knowledge and experience of software engineers and practitioners can ward off these evils. The chapter then discusses the models and methodologies for knowledge and experience management in software engineering. Finally, the chapter sheds light on the major works carried out in this area and suggests possible future research avenues in this domain.

Software engineering has been taught over the years using expositive classes, but learning this discipline requires more than just theory. Lately, universities started teaching software engineering in a theoretical-practical way. Typically, these experiences involve the development of software projects in the academia, using industry-oriented or ad hoc processes. However, most of them are not fully formalized, therefore it is not possible to repeat, measure or improve them. Moreover, it is not clear which project contexts are proper for each ad hoc process. This thesis work proposes to define and formalize a prescriptive software development process for use in undergraduate software engineering courses. We hypothesize that this process can make these experiences repeatable investing an affordable effort and will help produce positive results in student projects. This software process will be evaluated in the context of a second software engineering undergraduate course at the University of Chile, and it will address specific project contexts. This software process could be used in any university that has a similar course context. The proposed process can also be adapted to fit with new contexts.

Empathy, defined as the ability to understand and share others’ perspectives and emotions, is essential in software engineering (SE), where developers often collaborate with diverse stakeholders. It is also considered as a vital competency in many professional fields such as medicine, healthcare, nursing, animal science, education, marketing, and project management. Despite its importance, empathy remains under-researched in SE. To further explore this, we conducted a socio-technical grounded theory (STGT) study through in-depth semi-structured interviews with 22 software developers and stakeholders. Our study explored the role of empathy in SE and how SE activities and processes can be improved by considering empathy. Through applying the systematic steps of STGT data analysis and theory development, we developed a theory that explains the role of empathy in SE. Our theory details the contexts in which empathy arises, the conditions that shape it, the causes and consequences of its presence and absence. We also identified contingencies for enhancing empathy or overcoming barriers to its expression. Our findings provide practical implications for SE practitioners and researchers, offering a deeper understanding of how to effectively integrate empathy into SE processes.

Software engineering (SE) educators are challenged to balance the scope and depth in their courses to train students in skills which will fulfill the ever-evolving industry needs. Capstone courses are a tool for educators to transfer hands-on experience into practical knowledge and skills of SE students. This paper describes the design of a Casptone course, at Lappeenranta University of Technology. The designed course is human-centric SE capstone, infusing design thinking methods and agile practices into the project life-cycle knowhow. The capstone was offered in spring of 2017 as a 16-week course for 29 students. Design thinking was effective to perform requirement elicitation, software design and testing. Also, the applied approach allowed students to be self-directed which increased their motivation, as a result there was zero dropout rate. Design thinking is a powerful mean of problem solving and effectively supports SE education in bringing a more hands-on and minds-on, problem-based curriculum.

The International Conference on Software and System Processes (ICSSP), continuing the success of Software Process Workshop (SPW), the Software Process Modeling and Simulation Workshop (ProSim) and the International Conference on Software Process (ICSP) conference series, has become the established premier event in the field of software and systems engineering processes. It provides a leading forum for the exchange of research outcomes and industrial best-practices in process development from software and systems disciplines. ICSSP 2018 was held in Gothenburg, Sweden, 26-27 May 2018, co-located with the 40th International Conference on Software Engineering (ICSE). The theme of ICSSP 2018 was studying \Demands on Processes, Processes on Demand" by recognizing the demands on processes that include the need for both welldeveloped plans and incremental deliveries (agile and hybrid processes), utilization of increased automation (model-based engineering and DevOps), higher degrees of customer collaboration, comprehensive analysis of existing products for reuse (open source and COTS), and performance requirements of enterprise-level architectures. Papers presented at ICSSP discussed these issues across different domains, providing concepts, evidence, and experiences.

Software process is the most important part of software project management, and software process models are important means of implementing the software process in any software organization. When there is need to improve the software process, then the need to improve the work-task part (software process models) of the software process must arise. As, there is need of increasing the commitment of software project managers through out the software development life cycle (SDLC), so we need to give them the list of activities in Waterfall Model, which should be made efficient by the software development team, to get the 80% productivity (output) easily, by reducing the effort of software development and ultimately increasing the performance of the software process. So, the idea of 80/20 rule (Pareto Principle, 1935) can be applied in the software engineering process model, in this regard. The Pareto Principle (1935) directed us to focus on what is really important in any field and field's work. Software process is most important part of software project management (SPM). This is also then ultimately needed for software project management (SPM) improvement. Our main research work is to improve the work-task part of the software process (i.e. software process models by applying the Pareto Principle - 80/20 Rule (1935) (or law of vital few) (1935), in the software engineering process models (or work-task part of the software process). This will be to facilitate the software project manager, using the software process models practically more efficient than without application of 80/20 Rule in software engineering Waterfall model. This has resulted in the reduction of the software development effort and increase in the performance of the software process. The results (efficient and improved software process models) will be implemented in the software industry, by software project managers, by focusing on the list of activities giving 80 percent of the overall productivity of the software process. The results will be the list of activities having the capability to give 20 percent of the overall productivity of the software Waterfall process, to be ignored, eliminated or designated to reduce the effort.

article Free Access Share on The software engineering process: definition and scope Author: W. S. Humphrey Software Engineering Institute, Carnegie-Mellon University Software Engineering Institute, Carnegie-Mellon UniversityView Profile Authors Info & Claims ACM SIGSOFT Software Engineering NotesVolume 14Issue 4June 1989 pp 82–83https://doi.org/10.1145/75111.75122Online:01 April 1988Publication History 23citation2,737DownloadsMetricsTotal Citations23Total Downloads2,737Last 12 Months164Last 6 weeks13 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Most engineering curricula in the United States include some form of major design project experiences for students, such as capstone courses or design-build-fly projects. Such courses are examples of project-based learning (PBL). Part of PBL is to prepare students—and future engineers—to deal with and prevent common project failures such as missing requirements, overspending, and schedule delays. But how well are students performing once they join the workforce? Unfortunately, despite our best efforts to prepare future engineers as best we can, the frequency of failures of complex projects shows no signs of decreasing. In 2020 only 53% of projects were on time, 59% within budget, and 69% met their goal, as reported by the Project Management Institute. If we want to improve success rates in industry projects, letting students get the most out of their PBL experience and be better prepared to deal with project failures before they join the workforce may be a viable starting point. The overarching goal of this dissertation is to identify and suggest improvements to areas that PBL lacks when it comes to preparing students for failure, to investigate student behaviors that lead to project failures, and to improve these behaviors by providing helpful feedback to students. To investigate the actions and behaviors that lead to events that cause failures in student projects, I introduced “crowd signals”, which are data collected directly from the students that are part of a project team. In total, I developed 49 survey questions that collect these crowd signals. To complete the first part of the dissertation, I conducted a first experiment with 28 student teams and their instructors in two aerospace engineering PBL courses at Purdue University. The student teams were working on aircraft designs or low-gravity experiments.Does PBL provide sufficient opportunities for students to fail safely, and learn from the experience? How can we improve? To identify areas that PBL may lack, I compared industry failure cause occurrence rates with similar rates from student teams in PBL courses, and then provided recommendations to PBL instructors. Failure causes refer to events that frequently preceded budget, schedule, or requirements failures in industry, and are identified from the literature. Through this analysis, I found that PBL does not prepare students sufficiently for situations where the failure cause missing a design aspect occurs. The failure cause is fundamentally linked to proper systems engineering: it represents a scenario where, for example, students failed to consider an important requirement during system development, or did not detect a design flaw, or component incompatibility. I provided four recommendations to instructors who want to give their students more opportunities to learn from this failure cause, so they are better prepared to tackle it as engineers. Is crowdsourced information from project team members a good indicator of future failure occurrences in student projects? I developed models that predict the occurrence of future budget, schedule, or requirements failures, using crowd signals and other information as inputs, and interpreted those models to get an insight on which student actions are likely to lead to project failures. The final models correctly predict, on average, 73.11±6.92% of budget outcomes, 75.27%±9.21% of schedule outcomes, and 76.71±6.90% of technical requirements outcomes. The previous status of the project is the only input variable that appeared to be important in all three final predictive models for all three metrics. Overall, crowdsourced information is a useful source of knowledge to assess likelihood of future failures in student projects. Does targeted feedback that addresses the failure causes help reduce failures in student projects? To improve student behaviors that lead to project failures, I used correlations between failure measures and the crowd signals as a guide to generate 35 feedback statements. To evaluate whether the feedback statements help reduce project failures in the student teams, I conducted a second experiment at Purdue University with 14 student teams and their instructors. The student teams were enrolled in aircraft design, satellite design, or propulsion DBT courses. The student teams were split in two treatment groups: teams that received targeted feedback (i.e., feedback that aimed to address the failure causes that the specific team is most prone to) and teams that received non-targeted feedback (i.e., feedback that is positive, but does not necessarily address the failure causes the specific team is most prone to). Through my analysis, I found that my targeted feedback does not reduce the failure occurrences in terms of any metrics, compared to the non-targeted feedback. However, qualitative evaluations from the students indicated that student teams who received targeted feedback made more changes to their behaviors and thought the feedback was more helpful, compared to the student teams who received non-targeted feedback.

AboutSectionsView PDF ToolsAdd to favoritesDownload CitationsTrack CitationsPermissionsReprints ShareShare onFacebookTwitterLinked InEmail Go to Section HomeInterfacesVol. 31, No. 5 Linking Operations Management Students Directly to the Real WorldSanjay L. AhireSanjay L. AhirePublished Online:1 Oct 2001https://doi.org/10.1287/inte.31.5.104.9653AbstractLinking business students in operations management (OM) directly to real-world operations improvement experiences in manufacturing and service organizations resulted in 70 OM student field projects during the academic year 1998-1999 at Indiana University South Bend. The projects helped client organizations to identify strategies to improve quality, flexibility, and speed of operations, streamline processes, enhance customer satisfaction, reduce costs, and improve profits. Students gained valuable professional experience. The supervising faculty member and the institution enhanced their professional and community participation. The shared experiences should stimulate business schools and industries to implement this totally integrative experiential approach to OM course instruction. Previous Back to Top Next FiguresReferencesRelatedInformationCited byAdvising Student-Driven Analytics Projects: A Summary of Experiences and Lessons LearnedAaron Babier, Craig Fernandes, Ian Yihang Zhu26 August 2022 | INFORMS Transactions on Education, Vol. 23, No. 2It's not you, It's me: Can others learn from the challenges of teaching operations and supply chain management?The International Journal of Management Education, Vol. 20, No. 2Determining the causal relationship among the research streams of the operations management course16 October 2018 | Journal of Education for Business, Vol. 94, No. 3Multi-criteria analysis of professional education on supply chain management1 January 2019 | Production, Vol. 29A Survey of Research in Field-Based Education: A Summary of Process, Best Practices, and Lessons LearnedMichael F. Gorman20 November 2017 | INFORMS Transactions on Education, Vol. 18, No. 3Connecting industry and supply chain management education: exploring challenges faced in a SCM consultancy moduleSupply Chain Management: An International Journal, Vol. 18, No. 4Metodología docente y evaluación por competencias: una experiencia en la materia Dirección de ProducciónInvestigaciones Europeas de Dirección y Economía de la Empresa, Vol. 18, No. 3Student Reactions to the Field Consulting Capstone Course in Operations Management at the University of DaytonMichael F. Gorman, 11 July 2011 | Interfaces, Vol. 41, No. 6NC State's Supply Chain Resource Cooperative Educates in the Real WorldRobert B. Handfield, Steven A. Edwards, Jeffrey S. Stonebraker, 1 December 2011 | Interfaces, Vol. 41, No. 6Project-Based ORMS Education15 October 2012Mejorando la formación en Dirección de Operaciones: la visión del estudiante y su respuesta ante diferentes metodologías docentesCuadernos de Economía y Dirección de la Empresa, Vol. 14, No. 1The University of Dayton Operations Management Capstone Course: Undergraduate Student Field Consulting Applies Theory to PracticeMichael F. Gorman, 1 December 2010 | Interfaces, Vol. 40, No. 6Practitioner Perceptions of the A3 Method for Process Improvement in Health CareDecision Sciences Journal of Innovative Education, Vol. 8, No. 1Graduate Student Project: Operations Management Product PlanJournal of Education for Business, Vol. 83, No. 2Application of POM to e‐business: B2C e‐shoppingInternational Journal of Operations & Production Management, Vol. 23, No. 1 Volume 31, Issue 5September-October 2001Pages 1-143 Article Information Metrics Information Published Online:October 01, 2001 © 2001 INFORMSCite asSanjay L. Ahire, (2001) Linking Operations Management Students Directly to the Real World. Interfaces 31(5):104-120. https://doi.org/10.1287/inte.31.5.104.9653 KeywordsPROFESSIONAL—OR/MS EDUCATIONPROFESSIONAL—OR/MS IMPLEMENTATIONPDF download

Software engineering environments have a history of about two decades. Early environments provided support for small fragments of the software process (usually focusing on programming-in-the small). Then there was a trend towards support for more complete software processes (from early phases like requirements analysis and design down to testing and configuration management). Ten years ago the notion of process-centered software engineering environments initiated a new field in software engineering: software process research. The key idea is to use a model of a software process as input parameter for a software engineering environment. The environment is supposed to “behave” in accordance to the process model. Some aspects of this vision became true, others turned out to be of little practicability. In this article, we discuss the history of software engineering environments with a particular focus on process-centered software engineering environments (PCSEEs). We discuss the notion of distributed software processes (as one of the most substantial current trends in software process research) and we motivate the notion of a software process middleware which serves as basis of real-world software processes spread over various sites. In addition, we discuss some other trends in the software process research arena.

The software engineering process is a growing concern for many software development organizations. The need for well-educated software engineers is bringing new software engineering programs to universities. In many programs, software process education adds up to a few hours of lectures in an introductory software engineering course. This paper presents the structure and the content for a full, one-semester course on software processes, which has been designed in close collaboration with industry. The course is based on a software process called UPEDU (Unified Process for EDUcation), pronounced Yoopeedoo, and has been customized from the Rational Unified Process (RUP) for the educational environment. Many artifacts derived from a project case study are used as examples or templates. The content of the course is oriented towards the cognitive skills needed to perform the various activities required in the software process.

One of the most intractable problems in software is getting engineers to consistently use effective methods. The Software Engineering Institute (SEI) has worked on this problem for a number of years and has developed effective methods for addressing it. This paper describes these methods and shows what they have accomplished with several hundred students and working engineers. After first describing the problem of changing engineers’ practices, the paper discusses the logic engineers typically follow in deciding what methods to use. Next is a description of the Personal Software Process (PSP) and the Team Software Process (TSP). Finally, the implications of SEI’s experiences with the PSP and TSP are described, with particular emphasis on software engineering and computer science education.