The current ACM and IEEE Computer Society recommended guidelines for graduate software engineering programs (GSwE2009) were created in 2009 by an international group of experts from industry, government and academia. We report here on some of the early experiences using GSwE2009 to create a new curriculum in software assurance and to create and/or improve 4 different academic programs in 3 countries. All of these experiences have been positive, confirming the validity and usefulness of GSwE2009.
This paper describes an ongoing pilot project to develop a marketplace for multidisciplinary systems engineering capstone projects. Students from six different universities have applied to projects that were posted to the marketplace website by sponsors from government and industry. Each team includes students from different disciplines and different schools. The goals of the pilot project are to determine the requirements for a global electronic marketplace and to develop guidelines for faculty, students and sponsors who would use it.
This Software Assurance (SwA) Competency Model was developed to create a foundation for assessing and advancing the capability of software assurance professionals. To help organizations and individuals determine SwA competency across a range of knowledge areas and units, this model provides a span of competency levels 1 through 5, as well as a decomposition into individ-ual competencies based on knowledge and skills. This model also provides a framework for an organization to adapt the model’s features to the organization’s particular domain, culture, or structure.
Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (SE 2004) is one volume in a set of computing curricula adopted and supported by the ACM and the IEEE Computer Society. In order to keep the software engineering guidelines up to date the two professional societies began a review and revision project in early 2011. This special session will present the results of the review, present a first draft of the revision, and provide time for discussion and input from the computing education community.
This column discusses some of the recent reports about the shortage of STEM workers in the US and the possible causes of that shortage. In particular it describes several ways that students are diverted from STEM careers. Software engineers are probably diverted in the same ways.
This column describes recent progress teaching software engineering to large audiences via Massive Open Online Courses. A course taught by Armando Fox and David Patterson at Berkeley and on Coursera (now moving to EdX) is used as a recent successful example of this approach.
Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (SE 2004) is one volume in a set of computing curricula adopted and supported by the ACM and the IEEE Computer Society. In order to keep the software engineering guidelines up to date the two professional societies established a review project in early 2011. This paper describes that review effort and plans to revise the guidelines over the next year and a half.
This column features an interview with Leigh Ann Sudol, a member of the advisory board for the Academy for Software Engineering (AFSE), a new high school in New York City designed to prepare students for careers in software and computing.
Two recent articles that question whether software engineering is really engineering raise issues worth considering.
We need to develop an annual survey of software engineering education programs, similar to the Taulbee survey for computer science programs. Data on graduation rates and faculty load would help us do a better job of planning.
One of our challenges as educators is timely incorporation of research into curricula that can be adopted by universities to ultimately improve software engineering practice. In this paper, we describe the work of the Master of Software Assurance curriculum project. This includes our sources, process, products, adoption strategies, and early adoption experiences. The project used research results, prior curricula, and documented bodies of knowledge to develop a new curriculum. We are now working with early adopters and employing a number of transition mechanisms as part of our strategy to further adoption in this critical area.
The importance and complexity of software systems require software engineers who possess the appropriate skills, knowledge and experience to develop, maintain and acquire such systems. Graduate education is a key ingredient in advancing the state of professional software engineering practice. This paper describes the principal features of a new reference curriculum for master's programs: Graduate Software Engineering 2009 (GSwE2009): Curriculum Guidelines for Graduate Degree Programs in Software Engineering. These features include the GSwE2009 guiding principles, preparatory knowledge, student outcomes, curriculum architecture, and a core body of knowledge. In addition, the paper includes discussion of the GSwE2009 project organization, process, and activities.
A summary of the some of the important standards and guidelines for software engineering education, including SE2004, GSwE2009 and SWEBOK. Includes a request to participate in a feedback survey on SE2004.
The fourth volume in the Software Assurance Curriculum Project led by a team at the Software Engineering Institute, this report focuses on community college courses for software assurance. The report includes a review of related curricula, outcomes and body of knowledge, expected background of target audiences, and outlines of six courses. The courses are intended to provide students with fundamental skills for continuing with graduate-level education or to provide supplementary education for students with prior undergraduate technical degrees who wish to become more specialized in software assurance.
NASA performed an independent investigation of Toyota's hardware and software in order to determine if faulty design or implementation was causing unintended accelerations. Their results exonerated Toyota and provide a useful case study in the use of sophisticated tools and methods to study software.
This report, the third volume in the Software Assurance Curriculum Project sponsored by the U.S. Department of Homeland Security, provides sample syllabi for the nine core courses in the Master of Software Assurance Reference Curriculum.
Modern society is deeply and irreversibly dependent on software systems of remarkable scope and complexity in areas that are essential for preserving this way of life. The security and correct functioning of these systems are vital. Recognizing these realities, the U. S. Department of Homeland Security (DHS) National Cyber Security Division (NCSD) enlisted the resources of the Software Engineering Institute at Carnegie Mellon University to develop a curriculum for a Master of Software Assurance degree program and define transition strategies for implementation. In this article, the authors present an overview of the Master of Software Assurance curriculum project, including its history, student prerequisites and outcomes, a core body of knowledge, and curriculum architecture from which to create such a degree program. The authors also provide suggestions for implementing a Master of Software Assurance program.
The development of a high-performance systems and software engineering workforce in a world of increasing complexity requires a foundation of authoritative knowledge and guidance in systems and software.
If your students are not learning how to construct secure and resilient software in school they may never learn, and they may unwittingly contribute to the insecurity of software systems. This column describes some helpful resources for teaching students how to build security into their products.
This report contains guidelines for master's level curricula in software assurance. The link is to the SEI website where the report may be downloaded. Additional reports in this series and useful educational resources may also be found there.
This column discusses the challenges of developing software for safety-critical systems. In particular, it describes the unique challenges of developing software for today's automobiles, and the need for multidisciplinary cooperation.
This column describes where to find some good material for teaching software engineering topics. It contains references to several websites with lecture notes, exercises, outlines and further references.
A recent paper by Jill Courte and Cathy Bishop-Clark from Miami University in the 2009 SIGCSE Technical Symposium on Computer Science Education reported on how well students differentiate between the five major computing disciplines Computer Science (CS), Information Technology (IT), Information Systems (IS), Computer Engineering (CE), and Software Engineering (SE).
A new set of guidelines for graduate software-engineering education was recently published by Stevens Institute of Technology. These recommendations were developed by a coalition formed in 2007 from academia, industry, government, and professional societies called the Integrated Software and Systems Engineering Curriculum (iSSEc) project, to create a reference curriculum that reflects current development practices and the greater role of software in today’s systems. The report, titled Graduate Software Engineering 2009 (GSwE2009): Curriculum Guidelines for Graduate Degree Programs in Software Engineering, is available at http://www.gswe2009.org. Earlier versions of this work used the name “Graduate Software Engineering Reference Curriculum (GSwERC).”
A new set of guidelines for
graduate software engineering education was
recently published by Stevens Institute of Technology.
A link to the new software engineering guidelines.
In a recent column in IEEE Software Tom DeMarco provocatively asks whether software engineering is past its prime. We respectfully disagree.
Engineering educators struggle with “soft” topics – topics which include a social element. Soft engineering topics are distinct from the scientific and mathematical underpinnings of engineering. Students frequently complain when these topics are integrated into engineering curricula. Engineering educators also express concerns that they lack both preparation and ability to teach these topics.
educators have an even greater problem. More soft
topics need to be included in a good software engineering program.
Furthermore, software engineering instructors need to remain current
with non-social best practices, which can leave little time to study
techniques to incorporate soft topics into the curriculum.
This paper is an attempt to alleviate the problem. We organize the soft topics necessary for a good software engineering program; present exercises to include them in software engineering courses so that students develop needed abilities and understand their importance ; and describe effective ways to evaluate student performance.
In this presentation we discuss a project to study best practices in industry and compare these with curricula recommendations for software engineering programs. We have designed a survey on software development practices and methods to be administered as widely as possible within the US and in other countries. This would pave the way to gain a better understanding of the perceived gap between industry and academia. We would like to present this idea to the workshop and to solicit feedback on the survey design; we would also be seeking additional contributors.
The software architecture
process depends on successful
involving cooperation among members of the design team, cooperation
between the design team and the clients, and cooperation between the
design team and the development organization. Cooperative learning is a
pedagogy that directly supports this type of teamwork. Through
cooperative learning students realize their interdependence, practice
face-to-face communication, recognize their individual accountability
to the success of the group, practice interpersonal and small-group
skills, and engage in frequent reflective processing of their
We have adapted cooperative learning to teach software architecture in two undergraduate software engineering programs. In traditional cooperative learning, students work on one team for an extended period. This helps foster acceptance of individual differences and promotes successful teamwork. In our courses we kept students together on the same teams, but we wanted students to play multiple roles: clients, architects, and developers. So, we let the teams change roles during the course. That is, for each project one team played the role of architects, while other teams played the roles of clients and developers. Student teams rotated roles on different projects throughout the term. A further variation in cooperative learning is that, to succeed on each project, three different teams also had to cooperate.
These innovations kept the benefits of cooperative learning while also exposing the students to 3 different perspectives as they progressed through their projects. This is especially important for software architecture, where the 3 perspectives must always be kept in mind. An additional benefit was that each student participated in 3 different projects, thus experiencing greater diversity of architectural challenges than would have otherwise been possible.
Some changes to the traditional classroom setting are necessary in order to practice this new method. Students need to work in small teams, 3 or 4 students at most, during regularly-scheduled classroom hours. The roles of individual teams must be scheduled so that sufficient time is available for each team to play each role. Fortunately, software architecture lends itself to short periods of intense team activity, with reporting and peer review of results later. We believe that this active learning style is an effective approach for most subjects, but especially for software architecture.
All software engineering courses face a daunting task: how to recreate within the classroom the environment of software engineering as it is practiced. There are three major difficulties to overcome: providing the cultural environment of professional software engineering, providing opportunities for learning by observation and imitation, and providing opportunities for constructive feedback from teammates. Each of these difficulties can be addressed, but some creativity may be required to solve them within the traditional classroom setting.
This paper describes the major trends and events in the history of Master of Software Engineering programs. Productivity statistics are reported, and curricula are compared. Special attention is given to the pioneering role of some of the early programs, such as Wang Institute of Graduate Studies and Carnegie Mellon University.
Test-first development is a practice of extreme programming designed to produce reliable software quickly. Rather than writing the code first, a software engineer first creates the tests that will demonstrate that the software works correctly. Coding follows and is often guided by the tests. Practitioners of this method claim that the discipline of developing the tests before the code focuses their attention on the right problems and yields cleaner code. Test-First Teaching is a method of course development that incorporates Instructional Design methods to create more effective instruction. The instruments that will be used to test students’ day-to-day learning of the course material – assignments and quizzes – are created first, and instruction is developed to meet the students’ needs. Components of Test-First Teaching are applied at both course and lecture levels. Test-First Teaching has been used successfully to develop courses for the new Bachelor of Science in Software Engineering program at Rose-Hulman Institute of Technology.
Assigning students to teams can be a time-consuming process, especially for cooperative learning teams. This paper describes the initial development and testing of a web-based system to assign students to teams using instructor-defined criteria, including criteria consistent with the cooperative learning literature. First, the instructor decides which attributes of students to measure in assigning teams. Next, students complete confidential surveys to determine their attributes. Finally, the instructor assigns a weighting factor to each attribute and the system assigns students to teams. The purpose of the system is to shorten the time to assign teams and to improve the likelihood that teams will satisfy an instructor’s criteria for team formation.
The Team-Maker system provides two web interfaces—one for the instructor and one for students. The instructor’s interface is used to create the survey and, once students have completed the survey, to assign students to teams in accordance with an instructor-defined weighting scheme. The student’s interface allows each student to complete the confidential survey. Features of the team-assignment system important to forming cooperative-learning teams include: the instructor decides which attributes or skills (e.g., grades in prior courses, GPA, writing skill) are to be distributed heterogeneously across teams; the prevention, if possible, of underrepresented minorities being outnumbered on a team; and matching student schedules such that members of a team have a reasonable expectation of being able to meet outside of class.
To test the system, 86 students already assigned to teams by instructors in four sections of a sophomore-level course completed the survey in Spring 2003. In this paper, the teams created manually by the instructors are compared to the teams suggested by the automated system. Results of initial testing are described and plans for future development are outlined.
There are currently over 20 Bachelor of Science in Software Engineering degree programs in the United States. The first accredited software engineering programs in the U.S. are likely in the 2002-03 cycle, and it is expected that the total number of such programs will continue to see steady growth for several years to come. The authors have provided a comparison of programs in order to determine what trends are emerging, which will benefit both current software engineering undergraduate programs, as well as those institutions which are thinking of creating new degrees of this type. The curriculum content of these programs are broken down by subject area and compared with curriculum models and accreditation criteria. The results of a survey of undergraduate software engineering programs worldwide that was conducted by the authors is used both to provide additional data about the U.S. programs, as well as to compare them as a group to their counterparts in other countries.
This paper describes the experiences of a small team of domain experts in re-engineering the configuration control software for the 5ESS(r) switch. The project consisted of three main phases: discovery, design, and deployment. During the discovery phase the team conducted a domain analysis of configuration control software. In the design phase the team created domain-specific languages and supporting tools. The deployment phase consisted of trial use and modification in response to feedback from users. Lessons learned during each of these phases are summarized.
A software product line is a family of products that share common features to meet the needs of a market area. Systematic processes have been developed to reduce dramatically the cost of a product line. Such product line engineering processes have proven practical and effective in industrial use, but are not widely understood. The Family-Oriented Abstraction, Specification and Translation (FAST) process has been used successfully at Lucent Technologies in over 25 domains, providing productivity improvements of as much as four to one. In this paper, we show how to use FAST to document precisely the key abstractions in a domain, exploit design patterns in a generic product line architecture, generate documentation and Java code, and automate testing to reduce costs. The paper is based on a detailed case study covering all aspects from domain analysis through testing.
In the Family-oriented Abstraction, Specification and Translation (FAST) domain engineering process for software production, a member of a software product family is automatically generated from a model expressed in a DSL. In practice, the time and skill needed to make the DSLs proved to be bottlenecks. FAST now relies on jargons, a kind of easy-to-make DSL that domain engineers who are not language experts can quickly make themselves. We report our experiences with jargons in the FAST process, and describe the benefits they provide above and beyond conventional DSLs for software production and other purposes.
During the last five years, the Switching and Access Solutions Group of Lucent Technologies has made a considerable investment in domain engineering. Much of this work has been motivated by a desire to reduce the software development interval. The use of domain engineering has helped to decrease considerably the time required to design and implement software. In this paper, we examine four domain engineering projects. We find that each project was guided by two sets of criteria for success---one addressing the concerns of good engineering practice and the other addressing the special needs of technology transfer. The five critical attributes of new technology identified by E.M. Rogers's Diffusion of Innovations---relative advantage, compatibility, complexity, trialability, and observability---play an important role in domain engineering. In the projects we examine, attention to these attributes helped shape the final products and the processes by which they were created.
Modern telecommunications systems are so complicated that informal languages are no longer sufficient for expressing their requirements. A brief introduction to the nature of requirements for telecommunication systems is given in this paper. The three standardized formal languages for telecommunications, Estelle, LOTOS, and SDL, are described and compared. Each language is evaluated, and a comparison of all three is offered. Throughout the paper a common example is used.
A recent trend in both the software engineering research and industrial communities has been to seek ways to systematically engineer software domains. One approach is to develop families of software and to invest in facilities for rapidly producing family members. This tutorial describes the commonality analysis process, a systematic approach to analyzing families. The result of the analysis forms the basis for designing reusable assets to rapidly produce family members. This in-depth course teaches the participants the principles underlying the approach and gives them a chance to perform a practice commonality analysis guided by experienced users of the process.
Numerous formal specification methods for reactive systems have been proposed in the literature. Because the significant differences between the methods are hard to determine, choosing the best method for a particular application can be difficult. We have applied several different methods, including Modechart, VFSM, Esterel, Basic LOTOS, Z, SDL and C, to an application problem encountered in the design of software for AT&T's 5ESS(TM) telephone switching system. We have developed a set of criteria for evaluating and comparing the different specification methods. We argue that the evaluation of a method must take into account not only academic concerns, but also the maturity of the method, its compatibility with the existing software development process and system execution environment, and its suitability for the chosen application domain.
We describe three case studies in the use of Basic LOTOS. The studies cover design recovery, requirements specification, and design activities. We also report lessons learned from the studies. Early lessons suggested changes to the syntax of the language used, and the need for some specific analysis tools. The last case study reports some of the results of these changes.
This annual report on graduate software engineering education describes recent SEI educational activities, including the 1988 SEI Curriculum Design Workshop. A model curriculum for a professional Master of Software Engineering degree is presented, including detailed descriptions of six core courses. Fifteen university graduate programs in software engineering are surveyed.
Master of Software Engineering (MSE) programs are relatively new. Starting such a program is expensive in terms of human and capital resources. Some of the costs are: preparation of new course materials, acquisition of sophisticated equipment and software, and maintenance of a low student/faculty ratio. In addition, MSE students and faculty have special needs, such as technical background and familiarity with current industrial practices.
Wang Institute's MSE
program has evolved rapidly in
response to many of
these demands. Capital expenditures have been large, and much time and
effort have been spent creating and polishing the curriculum. Constant
evaluation and refinement have proven invaluable in assuring the
success and growth of the program. Corporate donations provided
much of the original computing equipment. The Wang family provided an
endowment for the purchase of a campus, a former Marist Brother's
Juniorate Seminary. Faculty were recruited from academia and industry.