Course Group Status Report

1. Summary

Software engineering is a core area in the discipline of computer science. Over the last decade, software and information technology have been primary drivers of economic growth in the US. Developing reliable software, however, remains a challenge. A recent NIST report (June 2002) estimates that software errors cost the US economy 59.5 billion dollars annually. The software engineering course group plays a pivotal role in addressing this challenge by teaching good engineering practices, and in developing the appropriate professional and social ethics.

The software engineering course group consists of two sets of courses:

1. The "core sequence" (CSE 560, CSE 601, CSE 757, and CSE 758). These courses are intended for computer science majors and are, in fact, either required for the major (560 and 601), required for the software systems option (757), or strongly encouraged (758).
2. The "Applied Software Engineering sequence" (CSE 502, CSE/ECE 768, CSE/ECE 767, and CSE/ECE 794.R). These courses are intended for students from other science and engineering majors, but with an interest in state-of-the-practice software engineering principles. They form a cohesive curricular unit, with 502 serving as the prerequisite to 768, and 768 serving as a prerequisite to both 767 and 794R. It is important to recognize that all these courses except CSE 502 are appropriate for CSE/CIS majors to enhance their software engineering backgrounds.

The first course in the "core" sequence is CSE 560 ("System Software"). CSE 560 is the keystone course of the CSE curriculum: it is a required course for all CSE students and it serves as a prerequisite for the majority of upper-level courses. The technical content of this course centers on the tools (e.g., compilers, assemblers, linkers, loaders, operating systems) that bridge the semantic gap between the machine-level view of instruction execution and the applications developer view of programs. This course expands significantly on several topics that were first introduced in the software spine: teamwork, design, and technical writing. It is followed by CSE 757 ("Software Engineering") where principles of design, implementation, validation, and management of computer software are taught. There is some variation between sections: some instructors emphasize reading and discussing papers taken from the relevant software engineering literature, while others focus on lecture-based delivery of the material.

The final course in the core sequence is CSE 758 ("Software Engineering Project"), a course that fulfills CSE Capstone requirements. The major objective of this course is to ready students for the marketplace by exercising--through a significant, large-scale system project--the knowledge they have gained in previous software and software engineering courses. Course projects typically involve practical (real) problems for a larger client community. Specifically, upon completing this course, students will have applied their knowledge in: (i) software design, (ii) the Software Development Lifecycle (SDLC) and software development processes, and (iii) specific software development tools and techniques.

Also included in this group is CSE 601 ("Social and Ethical Issues in Computing"), a core course on the social, ethical, and legal issues that arise in the practice of the computing profession as well as in the application of computer technology. This course is structured around student presentations and debates on current issues in the field such as privacy rights, security rights, copyright laws, and antitrust laws. Emphasis is placed on oral communication and on the ability to hold and defend reasoned opinions.

In the Applied Software Engineering sequence, the first course, CSE 502, has largely traditional content. It is required to get engineering and science students with non-computing backgrounds “up to speed”. It focuses on standard introductory object-oriented concepts and programming language features that are routinely taught to undergraduate computing majors. Students who have this background already may skip this course. The next three courses, CSE/ECE 768, CSE/ECE 767, and CSE/ECE 794R, teach specific software engineering processes based on modern industry-standard technologies such as UML; iterative and incremental development; use-case analysis; component-based software engineering; Java technologies including Java Beans, reflection, and class loading; C# and .NET technologies from Microsoft; and distributed systems based on standards such as EJB, JSP, XML, SOAP Web Services, WS-* specifications, Indigo, etc.

Overall, students and faculty are generally satisfied with the courses in the software course group. CSE 560 remains one of the most challenging and intense courses in the curriculum, but it is also perceived by the students as one of the most relevant for their future professional careers. The initial offerings from the Applied Software Engineering course sequence have been well-received, although enrollment from outside the department has decreased in the last few years.

2. Detailed Analysis

2.1 Summary of the courses

CSE 502: This is a three-credit course that introduces non-CS majors to object-oriented programming. It is intended for science and engineering students (lab assignments are technical in this direction), and serves as the transition course for non-CS majors who wish to take the Applied Software Engineering sequence. Topics include object-oriented programming concepts, interfaces and classes, and some important and standard design patterns such as observer, abstract factory, and template method.

CSE 560: This is a five-credit course that serves as the keystone of the curriculum. It is a prerequisite to almost all upper-level courses and students generally take this course during their sophomore or junior year. The class meets for 4 lecture hours/week. The extra credits reflect the heavy lab component of the course.

The technical content of the course centers around system software (e.g., compilers, linkers, loaders, interpreters). The emphasis of the course, however, is as much on design, documentation, implementation, testing, teamwork, and communication skills as it is on the pragmatics of system software.

Over the course of the quarter, students design, document, implement, and test several projects. These are large programming assignments, some taking as many as 6 weeks to complete, depending on the instructor. Students are given a description of the abstract machine for which they are building the system software and a good description of the required functionality for each particular assignment (e.g., an assembler). Like many real-world engineering situations, however, the assignment specifications are somewhat incomplete and occasionally ambiguous. It is up to the students to address the omissions and ambiguities by soliciting information from their hypothetical client and by making appropriate design choices. Apart from design choices in their system requirements, students are also free to make many design choices in the completion of their assignments; for example, the implementation language and platform as well as the module decomposition, data structures, and algorithms. For most students, CSE 560 is the first time they will face ambiguous requirement requests and the first time they will be given significant latitude in how they satisfy these requirements.

CSE 560 is also the first time most students will be building programs that are too large to complete in a single sitting. At the beginning of the quarter, the class is divided into teams of four or five. Assignments are completed by the team as a whole, and the entire team is given a single grade (with the exception of 5% that is reserved for individual effort and is allocated according to a peer review by other group members). Teams are responsible for setting up regular meeting times and for partitioning the workload equitably. Teams do meet with the instructor during the quarter to get direct feedback on their design decisions as well as to analyze and discuss how well the team is working together. Peer evaluations are submitted regularly during the quarter and provide more insight into the team dynamics that have evolved. Students gain first-hand experience in the challenges involved with working with others. They learn the importance of proper task allocation, how to rely on others, and how to take responsibility for completing tasks both as individuals and as a group.

In addition to a working implementation, teams must also deliver extensive documentation in the form of a user's guide, a programmer's guide, a testing guide, and the minutes from all team meetings. CSE 560 is officially designated as a writing course. It is not uncommon for this documentation to exceed several hundred pages over the course of the term. Recently, some sections of the course have experimented with Web-based documentation. Some lecture time is set aside to address technical writing issues. For the first assignment, some draft documentation is submitted so that students can get feedback before submitting their first set of documentation. Also, the last assignment is a synthesis of the previous assignments into a single working system and hence much of the documentation submitted for this final assignment is a rewritten form of previously submitted and graded documentation. Also, the College of Engineering maintains a Technical Communication Resource Center whose mission it is to "assist students in the development of effective written and visual communication skills". Students are encouraged to avail themselves of this service. There are two recommended textbooks for CSE 560, one of which is a reference book and style guide for technical writing.

CSE 601: The primary objective is for each participant to become informed, and to develop reasoned opinions about the ethical, social, and legal dimensions of various situations that may be encountered by computer professionals, and about social issues that arise from computer technology. Participants will practice how to: hold an opinion, have reasons for one's opinions, change opinions when compelled by best judgment, and rationally discuss opinions in cooperative pursuit of truth and good practices. Additional objectives are to develop communication skills, both written and oral, and to encourage ethical and responsible behavior.

The class meets once a week, with a 90 minute time slot. Each student makes one 10 minute classroom presentation on an assigned topic -- either a report-style presentation or an assigned role in a debate. Debates follow a modified town-hall debate format with points of order and points of information. Each student also writes a three-page paper on a topic chosen from a list of possible topics.

The presentation grade is based on: effectiveness of communication, clarity, strength of preparation, accuracy of reported material. Students are given an opportunity to rewrite their papers based on instructor and grader feedback.

CSE 757: This is our software engineering survey course and is required for students in the Software Systems option. The course is a prerequisite for CSE 758 and CSE 772, and students generally take it during their junior or senior year. The class meets for three lecture hours per week.

The technical content of the course centers around issues in software engineering, especially those that are related to the development and maintenance of large software systems. The course studies the principles of design, implementation, validation, maintenance, and management of computer software, along with tools, methodologies, and environments for effectively applying these principles. Topics include project management, software risk analysis, software engineering life cycle models, process assessment, requirements analysis, software design, software configuration management, software quality assurance, software inspection, and testing techniques.

Students have the opportunity to learn the course material in a variety of ways. Students prepare for class discussions by studying selected readings from an assigned textbook and a collection of papers. The textbook is usually either "Software Engineering: A Practitioner's Approach" by Roger Pressman or "Software Engineering" by Ian Sommerville. Both of these textbooks are widely used by universities for similar software engineering survey courses. The collection of papers supplements the textbook and gives students an opportunity to study one topic in more depth (by reading the paper originally reporting the work) or to study important topics not included in the textbook (such as recent developments and results).

CSE 758: The major objective of this course is to ready students for the marketplace by requiring them to exercise the knowledge they have gained in previous software and software engineering courses on industry-specified real world problems. Specifically, upon completing this course, students are expected to have applied their software engineering knowledge to aspects of:

• Software design:
  • driven by non-functional requirements: scalability, security, usability and performance
  • Generating and evaluating design alternatives
  • Pattern-based software design
• The process of developing software:
  • Configuration management
  • Project management, planning, team structure, roles and responsibilities
  • Incremental and iterative, workbook-centered, object-oriented, agile, lean software development
  • Project planning
• Presenting work to an audience of peers
• Business issues in software development

Specific tools and techniques that students typically use include:

• Object oriented analysis, design and implementation work-products.
• Lean software engineering.
• Unified Modeling Language (UML) notation for some of the above work products.
• Configuration management tools (RCS, SCCS, Ant, Make, or other), and other miscellaneous tools - Web authoring tools, Word processing tools etc.
• J2EE tools and components: Java 2 SDK, servlets, JDBC, JUnit.
• .NET tools and components: SQL-Server, ASP.NET, C#.
• Documentation/Markup languages including HTML, XML, and Javadoc.

Projects in this course have been many and varied. Projects are mostly provided by industry organizations. Some organizations have also sponsored projects via small cash grants in return for any intellectual property developed in the course. In all cases, the external organization has assigned one or more of their personnel to work with the students - mostly in the provision of requirements, but also as mentors. Finally, industry representatives are invited to the mid-term and final presentations made by students, to act as the "instructor-for-a-day", and provide feedback on how the students are proceeding, with specific feedback on what portions of the projects could make a suitable employment portfolio.

The number of projects done in a quarter depends on the number of students in a section. One of the sections, taught by Dr. Rajiv Ramnath (course coordinator), typically assigned a project to sub-groups of 4-7 students. Other sections (taught by a variety of instructors) have typically assigned a single project to an entire section.

Projects have included:

1. A SmartCard system, as a secure access card as well as a cash card system.
2. A cable network DOCSIS-compliant network dimensioning tool user-interface and back-end, algorithmic logic for network provisioning. This project was sponsored by Cable Labs Inc. - a cable industry consortium. Also, in a separate project, a test management framework for the above tool was developed.
3. Several small components of "ERP" systems. In one such project - sponsored by Northwest Ohio Secure Systems (NWOSS) - the students were asked to architect a complete ERP system. This project was guided, managed and mentored by several industry professionals, under strict time constraints.
4. A sensor-network based traffic-management system.
5. A web-based referee-signup and management system for the Mid-Ohio Select Soccer League (MOSSL). This system was completely designed by the students to be (a) highly-scalable to support the 1000 or so MOSSL games that take place each week, as well as the end of season MOSSL tournaments that all take place in the weekend following each MOSSL session (b) to be highly-usable by non-web-savvy volunteer referees and (c) extensibly implement MOSSL registration policies.
6. A public assistance web-site. This was done in collaboration with graduate students from the School of Public Policy and Management, as an experimental inter-disciplinary inter-departmental collaboration.
7. A donation- and charity campaign-managment web-site for a non-profit food-bank NSI Columbus - a local charity that has, since 1980 - distributed over 300 millions pounds of food to the local population in need.
8. Rearchitecture of the corporate web-site for National Cash Register (NCR) Inc.
9. Design and implementation of an Erector toys e-commerce web site - including both the implementation of the web site functionality as well as applying search engine optimization (SEO) techniques to the page content to enable its higher ranking by search engines.

The use of real external projects, in almost all cases, has brought in significant and interesting complexity to the projects - much more so than if the instructor had formulated projects. Students have been very motivated because of the presence of a real customer. Some projects have been very successful, and are confidently showcased by both students and the instructors to external industry. Business requirements have been well-understood by students, and there is a clear to business and market requirements in the scope and design of the projects.

Each of these projects have required system and software design. The non-functional (design) requirements that students have concentrated on have primarily been UI requirements. The extremely high-performing group doing the MOSSL project considered scalability as a key design requirement, studying several design alternatives, and implementing connection pooling, caching, very lightweight templates and database optimizations. Another group (that did the SmartCard digital cash project) made security their primary design requirement, and brought in the use of considerable digital-cash technology. Many groups, do not develop a clear and systematic process of architecture and design - they spend most of the quarter learning and then fighting the technology in order to implement as much as possible of the functional requirements, and only start developing a design process towards the end of the quarter.

Students are required to make several presentations during the quarter to showcase their progress and solicit feedback and guidance. Students are also required two formal presentations - a mid-term one (45 minutes - 1 hour in length) and a final one lasting 2 hours. The mid-term presentation is made to the entire class, the instructor and an external evaluator. The final presentation is made only to the evaluator and the instructor because of the difficulty of scheduling times when the entire class can attend. Each student will present at least 4 times during a quarter. Students clearly benefit from this presentation experience, as evidenced by the improvement that they make over the course of the quarter.

Even though the purported goal of the course is for students to apply their prior academic knowledge to class projects, students do not typically come in with a great deal of directly applicable prior knowledge. This means that students have to learn new things - such as new technologies and methodologies as well as learn to develop skills for applying their prior knowledge (on their own, and with mentoring, but no formal lecture from instructors). We believe that this experience will set stage for life-long learning on the part of students - both in terms of expectations as well as ability.

We are of the considered opinion that many of the problems may be mitigated by a two-quarter Capstone sequence. This would provide more time for the course expectations to "sink in", and be met in a better manner. We are working towards enabling this.

CSE/ECE 767:

CSE/ECE 768:

CSE/ECE 794R:

2.2 Relation to rest of the program

CSE 502: The prerequisites for this course are calculus and introductory programming in any language and paradigm, which we would expect of most students in science and engineering; plus some additional programming experience beyond an intro course, which would would expect of students interested in studying applied software engineering if CS is not their major. CSE 502 is and alternate (i.e., non-CS major's) prerequisite for CSE/ECE 768. We are considering making it an alternate prerequisite for some other courses as well in order to support the proposed ASE graduate minor. For example, non-CS majors should be able to use it as a prerequisite for CSE 541 in place of CSE 221.

CSE 560: The prerequisites for CSE 560 are CSE 321 (or CSE 314 for Information Systems majors), CSE 360 (or ECE 265), and a second writing course. The CSE 321 (or CSE 314) requirement stems from the large programming assignments that form the lab component of this course. Students come to CSE 560 with a strong foundation in the use and implementation of components built in C++ using the Resolve discipline. The ideas of tokenizers and parsers introduced in CSE 321 are extended in CSE 560. The CSE 360 (or ECE 265) requirement stems from the topic of the programming assignments: system software. Students are expected to be familiar with the basics of architecture and some assembly language.

CSE 560 serves as a direct prerequisite for the initial courses in several sub-disciplines: CSE 655 (programming languages), CSE 660 (operating systems), CSE 680 (algorithms), and CSE 681 (graphics). Of these, CSE 655 and CSE 660 require a conceptual model of the underlying hardware including memory and program execution. CSE 655 and CSE 681 both have extensive programming assignments, and assume the student is comfortable writing large programs.

CSE 560 also serves as a direct prerequisite for: CSE 731, CSE 772, and CSE 778.

Finally, CSE 560 serves as a prerequisite for two other courses in this course group: CSE 601 and CSE 757. Please refer to the description of these courses, below, for an evaluation of this prerequisite relationship.

CSE 601: The only prerequisite for this course is CSE 560. This course does not directly use any of the technical content of CSE 560. There are two reasons, however, for this prerequisite. Firstly, students in CSE 601 must complete a significant writing assignment (a term paper). They benefit, therefore, from the writing experience gained in CSE 560. Secondly, students in CSE 601 are expected to have a certain academic sophistication and general familiarity with many aspects of the discipline of computer science. Students should therefore be taking CSE 601 in their junior or senior year. The CSE 560 prerequisite is a simple mechanism to ensure that CSE 601 is not taken too early in the program.

CSE 601 is not a prerequisite for any other course.

CSE 757: The only prerequisite for CSE 757 is CSE 560. There are two reasons that CSE 560 is a prerequisite for CSE 757. Firstly, CSE 757 builds on the experience that students have in CSE 560. CSE 560 serves as an introduction to many of the problems that occur during the software development and maintenance life cycle. It therefore motivates the techniques and solutions presented in CSE 757 for managing the complexities of this process. Secondly, students in CSE 757 are expected to have a certain academic sophistication and general familiarity with many aspects of the discipline of computer science.

CSE 757 serves as a prerequisite for CSE 772 ( Information Systems majors may take CSE 516 to satisfy the CSE 772 prerequisite instead).

CSE 757 also serves as a (the only) prerequisite for CSE 758. See the next paragraph for a description of the relationship between these courses.

CSE 758: The only prerequisite for CSE 758 is CSE 757. In CSE 757, students learn the principles and practice of software development. In CSE 758, students apply this knowledge in the design of a significant, large-scale system.

CSE 758 is not a prerequisite for any other course.

In summary, the prerequisites for the courses in the group are satisfactory. Although CSE 560 has many responsibilities as the prerequisite for most upper-level courses, it seems to be meeting these diverse needs well.

CSE/ECE 767:

CSE/ECE 768:

CSE/ECE 794R:

2.3 Relation to program outcomes

The courses in this group play a key role in meeting both CSE program outcomes as well as EC 2000 Criterion 3 outcomes. We first consider CSE outcomes and then the EC 2000 outcomes.

2.3.1 CSE Outcomes

The published objectives and outcomes for the BS-CSE program lists the following five groups of outcomes.

1. Students will:
   1. Demonstrate proficiency in the areas of software design and development, algorithms, operating systems, programming languages, information systems, and computer architecture.
   2. Demonstrate proficiency in relevant aspects of mathematics, including discrete mathematics and probability, as well as electrical circuits and devices.
   3. Successfully apply these principles and practices to a variety of problems.
2. Students will:
   1. Demonstrate an understanding of differential and integral calculus, and of statistics.
   2. Demonstrate an understanding of the basic principles of physics and at least one other laboratory-based science.
   3. Demonstrate an understanding of the basic principles of at least one other engineering discipline in addition to computing and electrical engineering.
3. Students will:
   1. Demonstrate familiarity with basic concepts and contemporary issues in the social sciences and the humanities.
   2. Demonstrate an understanding of social, professional and ethical considerations related to engineering in general and to computing in particular.
4. Students will:
   1. Demonstrate an ability to work effectively in teams.
   2. Demonstrate an ability to communicate effectively.
5. Graduates will:
   1. Find suitable positions in industry and government that offer the prospect of challenging and rewarding careers in computing.
   2. Demonstrate an ability to acquire new knowledge in the computing discipline and to engage in life-long learning.
   3. [Graduates with an aptitude for, and interest in, graduate studies will] Apply to and be accepted for entry by strong graduate programs in computing.

This group of courses strongly contributes toward meeting outcomes I.i, I.iii, III.i, III.ii, IV.i, IV.ii, V.i and V.ii; moderately toward outcome V.iii; and to a limited extent toward outcomes I.ii and II.i.

The software engineering course group contributes significantly to objective I.i. In CSE 560, students are exposed to software design and development for large systems, and they design their first large software system. In CSE 757, they study the principles and practices that guide the development of software systems, and in CSE 758, they use these principles to design a software system. The software engineering sequence also contributes significantly to objective I.iii. In CSE 758, the projects come from real (external) clients and carry with them the full breadth of functional and nonfunctional requirements. Students tackle a wide variety of problems as they address a wide variety of considerations such as: correctness, UI usability, response time, throughput, scalability, and security.

The "social, professional, and ethical considerations related to... computing" are exactly the substance of CSE 601. This course, therefore, contributes significantly to objective III.ii

The software engineering sequence contributes significantly to objective IV.i by repeatedly requiring students to work in teams. All assignments in CSE 560 are done by teams of 4 or 5 students. These assignment involve using a variety of skills to address the range of required tasks (implementation, quality control, documentation). Teamwork also plays a central role in CSE 758, although the precise structure of the teams varies between instructors. In some sections, the entire class has been structured as a matrix organization with cross-functional teams working towards a single unified goal. In other sections, the class has been strictly subdivided into independent teams each with similar or independent goals.

Written communication is a key component of many of the courses. CSE 560 focuses on technical writing, requiring extensive technical documentation of various aspects of the delivered product (e.g., use, maintenance, and testing). CSE 758 also has significant documentation requirements, and CSE 601 requires a term paper. Some sections of CSE 757 use written paper summaries where students report on a paper in the literature.

CSE 601, on the other hand, focuses primarily on oral communication, with weekly individual presentations and team debates. Students learn how to communicate their views effectively and persuasively in several ways. Firstly, some lecture time is set aside for instruction in the mechanics of presentation/rhetoric. Secondly, the instructor makes topic presentations similar in style to what is required of the students, so they have the opportunity to learn by example. Finally, students receive direct and immediate feedback both from the instructor and their fellow classmates. During debates, each audience member chooses which side to support and sits on the corresponding side of the room. As the debate progresses and audience members move back and forth, speakers see immediately which arguments are persuasive and which are not.

The software engineering sequence contributes significantly to objective V.i. Students report that during their job interviews, they are asked to discuss many of the topics that they study in CSE 757, and that, because of what they have learned in the course, they are knowledgeable about the topics. Students also report that their potential employers are very impressed with the experience in software design that CSE 758 gives them.

The contribution that these courses make toward meeting various CSE outcomes is summarized in the following table:

2.3.2 EC 2000 Criterion 3 Outcomes

EC 2000 Criterion 3 requires that engineering programs must demonstrate that their students attain:

1. an ability to apply knowledge of mathematics, science, and engineering
2. an ability to design and conduct experiments, as well as to analyze and interpret data
3. an ability to design a system, component, or process to meet desired needs within realistic constraints such as economic, environmental, social, political, ethical, health and safety, manufacturability, and sustainability
4. an ability to function on multi-disciplinary teams
5. an ability to identify, formulate, and solve engineering problems
6. an understanding of professional and ethical responsibility
7. an ability to communicate effectively
8. the broad education necessary to understand the impact of engineering solutions in a global, economic, environmental, and societal context
9. a recognition of the need for, and an ability to engage in, life-long learning
10. a knowledge of contemporary issues
11. an ability to use the techniques, skills, and modern engineering tools necessary for modern engineering practice.

This group of courses strongly contributes toward meeting criteria 3c, 3d, 3e, 3f, 3g, 3h, and 3j; and moderately toward criteria 3i and 3k, 3e.

The contribution that these courses make toward meeting various EC 2000 Criterion 3 outcomes is summarized in the following table:

2.4 Feedback

The principal official vehicle for student feedback has been student evaluations in the form of SETs. These have generally been very positive, even for courses with high loads (CSE 560 and CSE 758). These courses require a great deal of effort on the part of the students, but this effort seems to be worth the benefit reaped (and perceived by the students).

Unofficially, many students have communicated (either in person or by email) how useful the upper level software engineering courses have been in their subsequent employment. Some have observed that the CSE 757 background has been useful during interviews for actually securing second interviews or even job offers. Others have commented how invaluable the design and analysis components of CSE 758 have turned out to be in their employment.

A third form of feedback -- and one that is particularly important to the software engineering sequence -- is from practitioners in industry. In addition to alumni surveys that give general indications of the success of various aspects of the program as a whole, CSE 757 and CSE 758 have benefited in particular from a great deal of input and interaction with practicing software engineers.

Paul Sivilotti, the course coordinator for CSE 560 was recently recognized with the department's annual Outstanding Teaching Award.

2.5 Major changes since the previous report

The last Software Engineering course group report was completed in Spring of 1999.

New "Applied Software Engineering" Sequence: By far the most significant change in this course group has been the addition of four new courses comprising the "Applied Software Engineering Sequence". Three of these courses now have permanent numbers and the fourth has been piloted twice and we will be requesting approval for a permanent number in the coming academic year. The department is currently in the process of developing this sequence into an Applied Software Engineering Graduate Minor, with a proposal going to the Graduate School in Au05. Among the contemplated course changes are a renumbering of 768 to 668, and offering CSE 502 as an alternate prerequisite for some 500- and 600-level CSE courses that should be accessible to non-CS majors who might enter this minor.

These courses have been designed together, as a curricular unit. The first course, CSE 502, is offered every fall. The second course, CSE/ECE 768, is offered every winter. The remaining two courses, CSE/ECE 767 and CSE/ECE 794R, are offered in alternating spring quarters.

These courses focus on state-of-the-practice software engineering techniques, applied in the context of traditional science and engineering problem domains. The sequence is intended to serve both computer science majors as well as other science and engineering majors from across the campus. The first class, CSE 502, is intended only for non computer science majors (it does not qualify as a technical elective for our majors). The other three classes, however, are taken by our students and have been well received. Class size averages around 20 students, with around half being from computer science.

Topics in CSE 601: The material covered in CSE 601 is under constant--and somewhat dramatic--revision. The topics and emphasis of the course are constantly changing to match what is in the current news as well as what is important to think about even when it is not in the news! Students, for example, might give presentations on intellectual property decisions related to Congressional hearings or court decisions in the same week they are actually happening. For example, this quarter (Spring 2005) one group of students presented on the broadcast flag requirement for digital TV the day before it was overruled by the courts. While course material certainly evolves over time (especially in a discipline such as ours), this is particularly true in CSE 601 where the topics can change from one quarter to the next. While this requires considerable dedication on the part of the instructor, the department has been fortunate to have someone (Mathis) who is up to the challenge (and even enjoys it). Certainly, the students seem to enjoy being in a course that incorporates topical news of the week.

Improvements in CSE 758: CSE 758 continues the focus on industry-sponsored projects, but has enhanced it by now requiring that each group does a different project. In addition to creating requirements, analysis, architecture, design and project management deliverables, students must now also implement a representative piece of the system that shows end-to-end traceability from requirements to implementation. Also, project groups are expected to define their software engineering process (as a hybrid of a planned and agile methodology) by considering characteristics of their environment and project. Other changes include:

• Multiple presentations throughout the quarter, and in particular, a mid-term and final presentation to the sponsor, as well as an external guest evaluator.
• Complete focus on the project - no exams, tests or quizzes.
• A refinement of the grading criteria to include "learning", "collaboration" and "mentoring".
• The inclusion of a session held by Engineering Career Services on interviewing.

2.6 Continuing and emerging concerns

Abstract machine in CSE 560: Traditionally, an "abstract machine" has been used as the target architecture for the systems software projects in CSE 560. This fictitious machine provides some flexibility to the course, as it can be varied from year to year and section to section, thus reducing the amount of inappropriate "cross-polination" of solutions between groups. An abstract machine also has the significant advantage of being simple. This is particularly important for CSE 560, where the student work load is consistently considered quite high.

Despite these advantages, working with a fictitious machine has a serious drawback: namely, a low level of student engagement. In general, it is easier to motivate students when the direct object of study is something with clearly real-world application. While parallels can be drawn (and are, in fact drawn) between the abstract machines and real architectures, the effect is not as dramatic as allowing the students to work with the real thing.

In response to this concern, one instructor (Stutz) has piloted a version of the class in which the target architecture is the 80x86. The intent is to keep the workload manageable by reducing the number of labs. The simulator lab, in particular, can be completely removed since the students can execute their machine code directly on real machines. We will continue this experiment in the upcoming academic year and evaluate whether to transition all sections to the 80x86 architecture.

Time constraint in CSE 601: The previous (Spring 1999) Software Engineering course group report noted the challenge in fitting CSE 601 into a 1-credit hour slot. That report suggested we consider:

"...expanding the time slot for CIS601 from 90 minutes to 2 hours. There is certainly enough material and issues to cover, but it isn't clear there is room in the core for a corresponding increase in the credit hours (from 1 to 2)."

Variance in CSE 757 sections: It has been many (6?) years since the official CSE 757 syllabus has been updated. In the meanwhile, the course content (and even the course structure) has evolved considerably. The net result is that there is significant variation amongst individual offerings of CSE 757. CSE 757 is often taught by adjunct faculty (from local industry). While the industrial perspective is a valuable benefit to the course, the frequent use of multiple adjunct faculty can exacerbate concerns with respect to variance.

One example of this variance is the degree to which papers from the SE literature are used. In some sections, students are assigned several readings over the course of the quarter, class time is devoted to discussing the papers, and written paper summaries are submitted. In other sections, the class is structured almost exclusively around lecture-based delivery of the material, with only one or two paper readings given as homework assignments. There is certainly a difference in the degree to which these approaches address program objectives (and EC 2000 Criterion 3 outcomes) involving communication. To the extent that CSE 757 is perceived as playing a pivotal role in meeting these objectives, we should ensure greater uniformity between sections in adopting and emphasizing an approach based on reading/discussing/summarizing papers from the relevant literature.

Perhaps more worrisome is the variance in the technical material covered by the various sections. This variance is a significant concern because it reflects a lack of intellectual identity in the course. Some instructors emphasize process (eg lifecycle, project management), others emphasize metrics, and others emphasize design (eg patters). As a result, the follow-on course (CSE 758) can not assume students have a uniform technical background. Thus, time is spent on teaching technical material in what should be a capstone course (CSE 758).

Addressing this concern will require a re-evaluation of the material in CSE 757, with particular attention to how it feeds into CSE 758 as well as how best to leverage the project experience that students receive in CSE 560. Another course with relevance to CSE 757 is CSE 616 ("Object-Oriented Systems Analysis"), although it is not a prerequisite. Rountev (the CSE 757 course coordinator) will work with Ramnath and Sivilotti (CSE 758 and CSE 560 coordinators respectively) to address this concern. An expected output of this activity is a fully revised official syllabus for CSE 757

It may be that a 600-level course number (657?) might be a more accurate reflection of the content of a course that is taken primarily by undergraduates. This direction was suggested by the previous Software Engineering course group report (Spring 1999).

Process in CSE 758: Establishing a software process has been difficult. When only planned processes have been required (RUP, IBM-OOTC), most of the time is spent reworking documentation. When agile processes have been permitted (XP), students have taken that as a license for no planning or formality at all. Further, students have packed and widely varying schedules, so the close contact required for agile processes to be applied has been hard to achieve for most groups. A promising approach has been to (a) give them limited choices of software methodologies (IBM-OOTC or XP only) and (b) require them to formally develop a hybrid process - with XP being used for components like the UI, and a planned process for backend system components. We have also learned how to better coach student groups in the development and establishment of an accepted process.

Impact of off-shoring: The recent trend in companies moving information technology jobs in general (and software implementation jobs in particular) to other countries, such as India, has received much attention in the press. At this point, it is unclear how significant this trend will be for the discipline of computer science in general, and for software engineering in particular. Some believe that, by its very nature, software is will be difficult to commoditize to the extent possible for more traditional, manufactured goods. In other words, the majority of software development will always require an agile, close collaboration with the end client. The skills needed by the next generation of software engineers will be a direct evolution from the current model. On the other hand, others believe that the off-shoring trend is a precursor to a dramatic change in the nature of software engineering in the US. While basic implementation and testing tasks can be out-sourced, higher-level tasks such as requirements analysis, design, and architecture will become increasingly important to software engineers in the US.

While we do not anticipate any significant, discontinuous alterations to the Software Engineering course group as a direct result of this trend, it is certainly an important phenomenon whose progress will be tracked.

3. Conclusions

The Software Engineering course group is an important component of the CSE program. It plays an especially important role in meeting the program objectives and EC 2000 Criterion 3 outcomes related to professional practice (eg teamwork and communication skills), professional ethics, and employability.

People involved in preparing report: Bob Mathis, Rajiv Ramnath, Atanas Rountev, Paul Sivilotti.

Date of report: June 2005.