Yoopeedoo (UPEDU): a process for teaching software process

Software Engineering is important for the students majored in computer science and technology. This curriculum is intended to provide students with an overall view over Software Engineering as an engineering discipline and with insight into the processes of software development. Creating software Engineering curriculum faces several challenges: (1) Software Engineering has wide coverage, but teaching time is limited. So it is difficult to make in-depth education. (2) Some introductory Software Engineering courses present the principles in isolation from practice. Teaching the lectures seems to focus on philosophy and methodology level, which leads to difficulty for students having no practical experience to understand. (3) Due to the lack of software project practice, students can hardly apply appropriate software engineering methods and technologies to solve problems. (4) How can Software Engineering curriculum satisfy the various needs of different levels? This paper focuses on the challenges above, and introduces how to try to solve them by a case study on the construction of Software Engineering curriculum at Peking University. Finally, this paper gives the future direction for the construction of Software Engineering curriculum.

The primary goal of an introductory software engineering course is to provide a complete introduction to software engineering. Typically this includes concepts, terms, processes, tools, and history. However, for students to fully understand software engineering and be prepared for software development careers, courses must also consider the sociological and communication aspects, often called the socio-technical aspects. Unfortunately, these aspects are difficult to teach and do not receive much coverage in the most widely used software engineering textbooks. Faculty have used various approaches to address the socio-technical aspects. One popular method is to use role-playing exercises. The software engineering education literature contains many papers advocating role-play. However, these papers describe role-play integrated in semester-long projects and often provide little detail about the exercises. Using these published approaches in an existing software engineering course requires significant work by the instructor. This paper presents a set of ready to use role-play exercises that can be downloaded and easily integrated into an existing course. Student reaction is also reported.

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

Computer and video games have grown to be a major industry but, until recently, have largely been ignored by academia. The last couple of years, however, have seen the emergence of new academic programs, conferences, and journals dedicated to games studies. For the past three years we have used computer games as projects in our introductory software engineering course. Small teams of students build three games across the semester. In this paper we describe the course and discuss its success.

Interfaces are fundamental in object-oriented systems. One of the principles of reusable object-oriented design, according to Gamma et al., is program to an interface, not an implementation. Interface-based systems display three key characteristics - flexibility, extensibility, and pluggability. Designing with interfaces is therefore a better way of building object-oriented systems. Getting students in introductory software engineering and design courses to program to interfaces and develop interface-based systems is a challenge. This paper presents our experiences with the use of mock objects to promote interface-based design and effective unit testing in software engineering and design courses.

In software engineering education, large projects are widely recognized as a useful way of exposing students to the real-world difficulties of team software development. But large projects are difficult to put into practice. First, educators rarely have additional time to manage software projects. Second, classrooms have inherent limitations that threaten the realism of large projects. Third, quantitative evaluation of individuals who work in groups is notoriously difficult. As a result, many software engineering courses compromise the project experience by reducing the team sizes, project scope, and risk. In this paper, we present an approach to teaching a one-semester software engineering course in which 20 to 30 students work together to construct a moderately sized (15 KLOC) software system. The approach combines carefully coordinated lectures and homeworks, a hierarchical project management structure, modern communication technologies, and a web-based project tracking and individual assessment system. Our approach provides a more realistic project experience for the students, without incurring significant additional overhead for the instructor. We present our experiences using the approach the last 2 years for the software engineering course at The College of William and Mary. Although the approach has some weaknesses, we believe that they are strongly outweighed by the pedagogical benefits.

Didactic experiences are very important in a Software Engineering course. We think they help to achieve at least six objectives of the course: to identify fundamental concepts of software engineering, to recognize software life cycles, models and methodologies of software development, to perform analysis of software products requirements, to design and develop a software product, to use the methodical processes of a real-world project, and to implement solutions following specific methodologies. In this paper we will show our didactic experiences in the Software Engineering Processes course. We developed a sequence of learning activities and their application (extracted from real requirements of clients and users) in different contexts such as environmental, medical and social, which results in higher levels of learning, interdisciplinary exercises and practices close to what students will face in their professional lives.

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.

A typical software engineering course consists of a series of lectures along with a small associated class project. Although this may seem like a logical approach, practical, didactic, and timing reasons necessarily lead to a lack of an in-depth treatment of the critical issues involved in the overall process of software engineering. This paper introduces and lays out our plans for constructing SimSE, a graphical, interactive, educational software engineering simulation environment that teaches the software process in a practical manner without the constraints of an actual class project. We anticipate that the use of SimSE will enable students to form a practical understanding of the software process by allowing its users to explore different approaches to managing the software process and giving them insight into the complex cause and effect relationships underlying the process.

Instruction in the theory and practice of the System Design Life Cycle is a significant component of introductory software engineering courses. In this study, project development pressures and management realities, which imitate those found in an industrial setting, were used to enhance student team projects. This paper examines the results of those constraints and presents an assessment of student experiences.

As software becomes more ubiquitous and complex, the cost of software bugs continues to grow at a staggering rate. To remedy this situation, there needs to be major improvement in the knowledge and application of software validation techniques. Although there are several software validation techniques, software testing continues to be one of the most widely used in industry. The high demand for software engineers in the next decade has resulted in more software engineering (SE) courses being offered in academic institutions. However, due to the number of topics to be covered in SE courses, little or no attention is given to software testing, resulting in students entering industry with little or no testing experience. We propose a minimally disruptive approach of integrating software testing into SE courses by providing students access to a collaborative learning environment containing learning materials on testing techniques and testing tools. In this article, we describe the learning environment and the studies conducted to measure the benefits accrued by students using the learning environment in the SE courses.

Software Engineering courses are perceived as being dry and boring. The education community has been looking at active learning and hands-on training techniques to engage students better and thereby provide a better understanding of concepts. This paper presents a web-based game called Scrumify, developed by undergraduate students, that is designed to introduce students to the Scrum software development process through story elements, and quiz mechanics. The game is designed to reinforce software engineering concepts more specifically agile software processes. Quizzes within the game are designed to grant points that inject a sense of competition for the users and motivation to learn the agile methodology concepts. Scrumify serves two objectives: software engineering education for audience of the game and web-based game development and software testing education for the developers of the game. Use of this game in classroom provides an active learning technique for agile software processes. Students are more engaged with games and thereby absorb the concepts better. The game was evaluated in a sophomore software engineering class and the results are presented.

One of the main concerns in the software industry continues to be the development of high quality software. This concern will be exacerbated as software systems become more complex. The training of software developers continues to grow in academia since more institutions are offering software engineering (SE) courses. However, the list of topics that are expected to be covered in this course leaves little or no time for topics that focus on developing quality software, such as software testing and the use of testing tools.In this paper we describe an approach that non-intrusively integrates the use of software testing tools in SE courses. The cornerstone of our approach is the interaction students have with a Web-Based Repository of Software Testing Tools (WReSTT) that contains tutorials on testing concepts and testing tools. WReSTT employs both collaborative learning and social networking features that are attractive to students. We present the results of preliminary study performed in two SE courses that show how using the resources in WReSTT can potentially impact the students' understanding of software testing and the use of testing tools.

The goals of computer science department and software engineering courses are not always clear as they could be, and exactly how much of a computer science curriculum should be spent on software engineering topics at the expense of topics with more immediate relevance to computer science majors is far from clear. Computer science students are sometimes skeptical about the relevance of software engineering course topics, particularly those who have had some experience in industry. They report that the techniques and procedures covered in standard software engineering texts are seldom used in industry. There is not enough communication between Industry and Academia, and graduates often must be re-trained for their new jobs. This is a proposal for a modification in the approach to software engineering education for computer science majors, and for clarification of the goals of computer science programs, and calls for procedures to increase the relevancy of computer science and software engineering courses to meet the needs of industry.

The evaluation of an advanced software engineering (SE) course is a challenging task that should be addressed as part of the course design. In this paper, we describe an implementation of the reflective practitioner perspective as part of an advanced SE course and introduce its use for feedback purposes. Reflective feedback goes beyond merely using feedback questionnaires. Furthermore, we show, using both qualitative and quantitative empirical data, that the course on which the perspective was applied meets its objectives and fosters students' awareness to the multidimensional nature of SE.