Forum for Advancing Software engineering Education (FASE) Volume 11 Number 06 (137th Issue) - June 15, 2001 Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents This Issue's Topic: Teaching Software Project Courses Introduction by Stan Jarzabek, Guest Editor Necessary Support for Students Who Take a "Project Course" by Y. Akiyama and Y. Matsumoto A Work Product Based Software Engineering Project Course by Jurgen Borstler Innovative Software Engineering Education by Larry Bernstein and David Klappholtz Software Engineering Project Course at University of Hawaii at Hilo by John Gersting An Undergraduate Software Engineering Project Course at UCSC by Donna Stidolph and Linda Werner A Software Project Course at Norwegian University of Science and Technology by Letizia Jaccheri A Software Engineering Project Course at the University of Texas at Austin by Vicki L. Almstrum Real Software Engineering Projects at the University of Sheffield by Mike Holcombe Software Engineering Project Course at Gannon University by Steve Frezza Software Engineering Project Course at California State University, Sacramento by Richard H. Thayer Using Critical Essays in a Project Course by Sally Jo Cunningham Projects in Real-Time Software Engineering Courses by Janusz Zalewski Software Engineering Project Course at National University of Singapore by Stan Jarzabek Upcoming Topics Software Engineering as a Profession in the United Kingdom Articles Ideas and Issues in Software Engineering Education by Tom Hilburn Book Reviews "Software Fundamentals: Collected Papers by David L. Parnas" reviewed by Don Bagert News Items ICSE Holds Panels on Software Engineering Education, SWEBOK New SE Professional Society Holds Workshop CCPE and Microsoft Agree on Use of "Engineer" Title UT-Dallas to Launch Software Engineering Degree Program Parnas Writes Pro-Licensing Article for Canadian Magazine Calls for Participation TOOLS USA 2001 Position Openings Illinois Wesleyan University Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Stan Jarzabek This Issue's Topic: Teaching Software Project Courses Guest Editor: Dr. Stan Jarzabek Department of Computer Science, School of Computing National University of Singapore Introduction: The below papers and reports describe academic project courses taught at thirteen universities. Not surprisingly, we find a wide range of approaches. Most of the courses emphasize the importance of exposing students to "real world" industrial experiences. Students have to clarify requirements with customers, while they work on the design and implementation. Some other courses emphasize application of "best practices" (such as architectural design and design for change) in a systematic way. Different types of project courses tend to focus on training different software development skills. Knowing how to communicate with customers concerned with business issues and how to deal with fuzzy and unstable requirements is as important as the ability to communicate with other members of the development team, apply architectural design, define component interfaces, design for change or plan incremental development. Students learn about these things in earlier courses, but only in a large-scale, team-based project students can really appreciate the practical value of what they have learned. In the April 2001 issue of FASE, Tom Hilburn calls for balanced software engineering curricula that would give equal attention to both "real world" experiences and applying software engineering principles. In the first paper below, Yoshiro Akiyama gives us an industrial perspective on academic project courses in which he further enforces Tom's views. Trying to address all the educational objectives within a single project course may be difficult, if not impossible. Perhaps, we should design a series of project courses that will let students gradually master different types of development skills, so that, at the end, our graduates know how to cope with challenges of real world projects in a systematic (i.e., based on principles and "best practices") rather than a chaotic way. We believe readers will find the perspectives on teaching project courses presented in papers below interesting and inspiring in refining their software engineering curricula. We also hope that papers will stimulate further discussion and exchange of opinions on this topic. ###################################################################### Title: Necessary Support for Students Who Take a "Project Course" Authors: Y. Akiyama, e-mail:akiyama@ieee.org IBM Global Services, IBM Japan Ltd. Y. Matsumoto, e-mail:yhm@sft.cs.musashi-tech.ac.jp Musashi Institute of Technology Abstract: This paper addresses key concerns on how to introduce software process and engineering disciplines into academic undergraduate level education in such a way that there is an understanding of the total picture of a software product development project as team effort. In industry, improving process and disciplines has been expected for realizing better quality and productivity in problem solving or competitive software systems product development. Such team (project) effort can be managed through software process for success. Detailed Description: Hilburn [1] brought up an interesting discussion, "... to what degree should a project course incorporate real world experiences?" where "Real World" addresses software projects in industry. In this short note, a few suggestions for designing the academic project course program are mentioned after discussing the characteristics of software projects in industry. One critical issue that we learn from an industrial project is how to deal with the complexity of projects. The complexity range may be measured by the attributes such as the size of product or deliverable, skill, process, stake holder's role, time duration, budget, contract, and the relations among them. It is noted that a staff member cannot execute a project alone, but it must executed by a group of staff members who have skills that effectively supplement each other. To cover the entire complexity range, multiple project (educational) courses are designed and provided in industry to help employees to develop skills and capabilities as a long-term education program with or without OJT (on the job training.) The scope of each course is defined according to the required technical matters (a project type), software process, and job roles, in addition to the importance of customer satisfaction and quality needed for the project's success, no matter how those items are theoretically related and integrated. Two ideas to improve the quality of the education program are introduced as follows. The prerequisite for a project course is specified to make sure that the students know the terminology, concepts, engineering disciplines, basic skills, and workable or best practices that are assumed. "Realistic training" is included so that the experience will help the attendees to understand what they would do for the goals of a similar project. After completing such a series of project courses, however, "trouble" may be found in the form of a project delay, skilled resource shortage, frequently changing requirements, or a lower quality of deliverables, just before the closeout phase. This may occur, although the project progress has been tracked, reported, reviewed, and agreed upon by the other stakeholders. Engineering on what and how staff members work together may be developed as the combination of engineering on a software system and engineering on a software process that is defined by the collection of activities, including technical decisions and workload estimations. Let us call the engineering on a software process as the software process engineering and the combination of the two engineering areas as the project engineering to distinguish them from one another. Industry practices and lessons learned should be understood based on project engineering view point, as long as they are technical. The initial components of project engineering may be software engineering components, TSP(SM), PSP(SM), and some basic quantitative practices for decision making and estimation. Interestingly, TSP(SM) and PSP(SM) provide practices to estimate (technically) the workload that comes from non-technical human error. Concerning project engineering, let us consider Hilburn's question. It is preferable for a student to develop skills and knowledge totally balanced from the project engineering viewpoint. In this sense, the industry's project practices and experiences may be introduced into the academic education but require very careful considerations. Undergraduate students learn the concepts and technologies included in the software engineering education course one by one at the beginning. For example, the object-oriented course may give lectures on such topics as object-type, inheritance and overloading one by one, and an exercise for each of the subjects. Let us consider what happens then if an exercise, "design a library system", is given in the last part of the software engineering course. This exercise includes many technical problems and problems related to the software process especially related to team working. It is noted that the students are really interested in how to apply The software engineering disciplines, just learned, to the given Problem and not in software process that is unknown to them. As easily expected, they may need to spend more time to define their software process in some way. Since this may appear meaningless to students, an appropriate software process must be given to the students in advance so that they apply the software engineering disciplines properly along with the software process and understand how it helps the application of the software engineering disciplines to produce the ultimate output. Similarly, the description of the software engineering disciplines needs to be given to students who have learned only the engineering of a software process. Thereby, solving the problem should be easily accomplished. It is interesting to note that students learn the TSP(SM) process by the textbook that describes the concept and the TSP(SM) process. Students are assumed to always know how to formulate problems at the application function level. Most likely a student who works well on this problem formulation, will communicate with others well in a different phase. The totality (integration) of engineering a software (system) and a software process should be designed in a project course so that students will be able to learn the importance of team working and how a realistic project is defined, executed, and controlled for maximizing the team's performance. References: T. Hilburn, "So Let's Make that Software Project Course 'Real-World'?", FASE, Volume 11, Number 4, April 2001. B. Cannon, T. Hilburn, and J.Diaz-Herrera, "Tutorial: Introduction to the Team Software Process(SM)", CSEE&T2000, Austin TX, March 2000. W.S. Humphrey, "A Discipline for Software Engineering", Addison Wesley Longman, Inc. 1995. (SM)PSP, TSP and Team Software Process are service marks of Carnegie Mellon University ###################################################################### Title: A Work Product Based Software Engineering Project Course Author: Jurgen Borstler (jubo@cs.umu.se) Institution: Dept of Computing Science, Umea University, SWEDEN Summary Page: The type of your project course: 1. Industry involvement: see below 2. Projects proposed and supervised by faculty members in areas of their expertise. 3. Project(s) formulated and conducted by a small number of faculty members specializing in Software Engineering, with faculty members and teaching assistants supervising student teams. 4. Other: please describe ==> 1 and 4: We accept project proposals from faculty members, external organizations, and industry (usually about half the projects have industry involvement); supervision by faculty members only. The project course is taught at: 1. undergraduate level 2. graduate level ==> Both: 3rd (75%) and 4th year students. The objectives of the project course: 1. degree accreditation concerns 2. professional licensing concerns 3. better prepare students for industrial projects, 4. develop ability to work in a team, 5. enhance communication skills and writing skills, 6. enhance project planning skills, 7. other objectives - please describe. ==> 3-6, 7: Teach some advanced OO concept; follow defined processes. Your project course is offered in the: 1. general Computer Science degree 2. Software Engineering degree 3. other - please indicate. ==> 1 Project workload: 1. project is a part of a general Software Engineering course 2. full-fledged project course with workload equivalent to: for example, a typical 1 term course (13 weeks, 3 lectures per week) ==> 2: 10 weeks half-time work, i.e. 200 work hours per student (includes all course related activities) Rating of the impact of the project course on the market value of graduates: 1 - low 5 - very high ==> 4-5 (qualified guess; no formal evaluations done, but positive feedback from alumni) Detailed Description: What follows is a short summary of a recent paper that will soon be published by the Journal of Computer Science Education. The major goal of our project courses is to give students some experience in non-trivial project work. Prior to our main project course all students take a basic software engineering course which comprises an introductory team project (5 weeks half-time work, 12-18 students per team). The main goal of this introductory project is to make clear the major differences between individual work and working in teams: - Without planning, coordination, and commitments a team will most likely not succeed. - Individual top performances are not sufficient to succeed. - Programming accounts for only a small fraction of the total work. The main goal of the second (main) project course is to run a non-trivial development project as professionally as possible. The project spans all phases of one iteration of an object-oriented development process. It starts with a problem definition and ends with the (public) presentation of a running prototype. A big problem with object-oriented development processes is that they not as straightforward as, for example, traditional waterfall-like models. In object-oriented development, there is no clear border between analysis, design, and implementation. Students therefore have difficulties deciding what to do when, how to do it, and why to do it. Over the years we have developed a work-product oriented development process to guide students through OO development. This process was partly inspired by IBM's Experience-Based Approach ([LiGu97]) and compares quite well with a scaled down version of the RUP ([Kru00]). A work-product oriented development process provides a framework for structuring and managing object-oriented development. Development can be defined in terms of interrelated work products. Each work product is defined by its purpose and contents, the inputs needed, and the techniques used to produce it. The definition of a development process and the production of a single work product are therefore more straightforward. Students work in teams of 5-7 students. Among others, our course design takes care of the following "misunderstandings": - Requirements are the customers' responsibility. Our projects start with more or less vague proposals. The student teams have to contact the customers* for details and the customers have the permission to change requirements during the projects. The message is "it is YOUR responsibility to get the requirements right." - Up-front work does not pay-off. To make clear the importance of careful design, clear specifications, and early development of test cases, each team must subcontract another team for developing a specific part of their own prototype. Next fall this course will be offered for the ninth time. Up to now 45 student teams (about 280 students in total) have completed the course successfully. Although the course lasts only 10 weeks, students are able to implement prototypes of significant size. Our experience shows that a work-product oriented approach helps students to organise and carry out their work. The course evaluations show that students like the course. The design of the course gives worthwhile insights into many new aspects of their future work. Several alumni reported that the course very well matched their situation at their workplaces. Many students comment that teamwork was more difficult than they assumed, but that this was an important lesson to learn. Students often complain about the heavy workload and the amount of programming involved in the project, but we think that a prototype must be built to validate analysis and design. For detailed information please check the course home page at http://www.cs.umu.se/kurser/TDBC18/HT00/ for the latest offering (material in English is marked by a flag). *Customers are usually local companies or staff not involved in teaching this course. References: [LiGu97] Dave Livesey, Tom Guinane: "Developing Object-Oriented Software, An Experience-Based Approach," Prentice Hall, 1997. [Kru00] Philippe Kruchten: "The Rational Unified Process, An Introduction," Addison-Wesley, 2000. Dr. Jurgen Borstler phone: +46 (90) 786-6735 Department of Computing Science fax: +46 (90) 786-6126 Umea University e-mail: jubo@cs.umu.se SE-901 87 Umea, SWEDEN URL: http://www.cs.umu.se/~jubo/ ###################################################################### Title: Innovative Software Engineering Education Authors: Professors Larry Bernstein and David Klappholtz bernstein@worldnet.att.net, d.klappholz@worldnet.att.net. Stevens Institute of Technology, Hoboken, NJ Software projects often fail because the staff lacks Software Engineering education or when they had it they fought it. To compound the problem they don't accept Software Best Practices. Our challenge is to overcome the natural biases of software professionals and computer science students. Reading case histories of failed software tends to convince some students of others' stupidity. While other students intellectually accept the existence of the problems, just reading about them does not convert many at the 'gut level.' At the gut level one sits up, takes notice, and does something different. Motivation Our approach is to force students to live through specific case histories, each one chosen to get across a small number of important issues. The method works. Students internalize the software engineering lessons and follow best practices to avoid the traps they experienced. Here is how the approach works. First, a set of software process issues is selected. Here are the ones we chose for our first live-thru case history: 1. the need to have close customer/user relations 2. the need for up-to-date documentation throughout the life of the project 3. the need to identify risks and to develop contingency plans 4. the need to account for human foibles Second, a case history based on a project facing these challenges is chosen. Students are not given the entire case history up front; rather, they are given the same problem/project as the actual developers who executed the case history faced. They are given no more information about the problem/project than were those developers. The project information is simplified to ease understanding. Background Computer Science is the study of the technology (State-of- the-Art) involved in the development of computer software. As it is usually taught in a post-secondary setting, Computer Science deals with "programming in the small," i.e., one-person or few-person software projects. Software Engineering, on the other hand, is the study of the method or process (State-of- the-Practice) whereby production software is developed -- "programming in the large." State-of-the -Practice includes both engineering practices and project management or group dynamic processes. Many post-secondary programs in Computer Science offer a Software Engineering or Senior Project course as a capstone. Because of the very different natures of technology on the one hand and method/process on the other, and because computer science students are typically technology-oriented and method/ process-averse, the typical Software Engineering course reaches far fewer future software developers than suits the best interests of either the students themselves or the software industry at large. We have developed a novel instructional method, the Live-Thru Case History method for addressing this problem, have developed a first live-thru case history, and have used it successfully in the first few weeks of a two-semester undergraduate Software Engineering course. The result was that students were shocked into an awareness of the Issues and how to deal with them in six weeks of two classes meetings a week. One class meeting was devoted to project meetings and the other to lectures on Software Engineering topics including other case histories. Conducting the Case History Because there would be only one live-thru case history in our Senior Project course, we had to choose one that would achieve the greatest effect in the limited time available. We chose the case history of a brief development project that one of the authors worked on, in 1985, as a public service project. The problem/project was that of automating an elementary school library's manual system for generating overdue-book notices. The class of forty students was divided randomly into four equal-size development teams. Students were given the same details, as were the original software developers in the case history. The instructor played the role of the customer, the school librarian, and was available to students, to respond to questions, both in class and by e-mail. Students were told that the customer would evaluate their work, exactly as work is evaluated in the real world. Results As is frequently the case in real software development projects, the Overdue book notice project had a hidden requirement that was so obvious to the customer that she failed to mention it; it is that overdue notices must be sorted, first by teacher name, then, for each teacher by class, and, finally, within each class by student's family name. The system analyst rejected the real software system when she first saw it. The original developers failed to elicit the hidden make-or-break requirement, and thus failed to satisfy it. Each of the student teams fell into this same trap and they learned the lesson of the need to find any 'hidden requirements.' The need for high-quality documentation and for contingency planning Were motivated for students by the classroom equivalent of the real-world phenomenon of loss of staff members due to illness, death, relocation, etc. At the midpoint of the project, the student from each team judged, by the instructor, to be the team's strongest developer and another, randomly chosen, team member were removed from the team and re-assigned to a different team. To evaluate the success of the staff change on students' approach to software engineering, after the case study project students were then asked to describe what they would have done differently had they understood that the real-world conditions under which they would be operating included the possibility of staff changes. About three quarters of the students mentioned the importance of up-to-date documentation, and about twenty percent had developed insight into appropriate utilization of staff, including the use of "understudies" and of preparation for the incorporation of new team members and thus demonstrated that they had learned the value of these processes. Evaluation of how well the students internalized the need for solid requirements engineering was done the end of the live-thru case history. A written exam was based on another case history. This case history included a more difficult requirements engineering problem than that of the overdue book notice project. About three quarters of the students showed that they had mastered the notion of hidden requirements, and about one third showed that they had achieved reasonable competence in requirements engineering; about ten percent showed extremely keen insight into the problem. Claims The innovative process of live-through case histories is more effective than the traditional teaching of the Software Engineering course. In the past students were given lectures, homework and exams based on a well-respected Software Engineering text. Then they were asked to develop a project. When they approached the project they could not readily apply the techniques they learned. Once they understood the need for the processes they re-learned them as they tried to apply them. Directions The authors are asking those teaching software engineering to use these case histories in their courses and report on the results. Materials are available at web site www.NJCSE.org along with a complete paper describing the live-thru approach in detail. Please participate in gathering data to support or refute the claims in this paper. It is our intent to use the experience of instructors in several venues to make anecdotal conclusions more meaningful and perhaps statistically significant. We invite those who agree with us to join a consortium for the purpose of creating additional case histories and helping to refine the process. ###################################################################### Title: Software Engineering Project Course at University of Hawaii at Hilo Author: John Gersting [johng@hawaii.edu] Professor of Computer Science Institution: University of Hawaii at Hilo Summary Page: The type of project course: 1. Industry involvement: yes (not-for-profit client) The project course is taught at: 1. undergraduate level The objectives of the project course: - professional licensing concerns - better prepare students for industrial projects, - develop ability to work in a team, - enhance communication skills and writing skills, The project course is offered in the: - general Computer Science degree Project Workload: -project is a part of a general Software Engineering course (two semesters) Ratint on the impact of the project course on the market value of Graduates (1-low to 5-very high): 3 Abstract: The Software Engineering sequence at UHH is a one-year (6 semester hours) project-based course. It is one of two junior/senior capstone sequences in the B.S. Computer Science degree (the other is a database sequence). The objectives of the course are: better prepare students for industrial projects, develop ability to work in a team, and enhance communication skills and writing skills. The project, which is a major part of a general Software Engineering course, involved developing a 3-tier client / server web-based application for an "outside, not-for-profit" customer. The Rational Unified Process was used as the development methodology. The project teams (3 to 6 teams depending on the iteration) were formed from the 22 students in the class. The course was delivered partly in a distance education mode (communication between sites used HITS- Hawaii Interactive Television System and WebCT courseware). Students were located on three different islands in the state of Hawaii: the Big Island (17), Maui (3) and Oahu (2). The instructor acted as the project manager. Detailed Description: The courses were run using a "workplace" metaphor. The students played the role of a "new hire analyst" into a software development shop. They had two basic missions, a training component where they studied software engineering principles from text and lecture material, and a work component where they participated in a team developing part of the project deliverables. The project development methodology followed the Rational Unified Process (RUP) and was supported by the Rational Suite Enterprise software. The RUP iterative development process involves four phases, Inception, Elaboration, Construction and Transition. The course project development involved five iterations: Elaboration 2, Construction 1, 2, 3, 4 and Transition. The first two iterations, Inception and Elaboration 1 - the requirements and specifications in the form of a Stakeholder and a Vision document - were prepared in advance for the start of the project. The motivation for starting with Elaboration 2 (finishing the specifications) was two-fold. Previous experience in this course led to the conclusion that a great deal of "thrashing" occurred in the requirements and specification portions of previous projects while the students were introduced to the concepts of software engineering through lecture material (design is hard). In previous waterfall methodology courses, the requirements and specifications consumed a semester; then when it was time for implementation to begin, the documents that had been prepared were largely ignored and final system integration was very difficult. During Elaboration 2 the teams learned about the project in an "actor-based" way, each team looking at the requirements and features needed for the use cases for a given actor. The deliverables were revised use case documents, a revised vision document, and a Rose model including a database design. The system architecture was 3-tier, IE browser, IIS, and SQL Server 7.0. The middle layer was constructed using ASP for control and a DLL for the database interface and generation of the HTML pages. For each iteration, each team had a Team Lead. The Team Lead interacted with the team members and the Project Manager on topics such as task assignments and progress. Each team member submitted a weekly time sheet based on his or her tasks. At the end of each iteration the Team Lead wrote an evaluation for each member of his or her team. Each student was a team lead sometime during the project. Construction 1 and 2 were dedicated to delivering a prototype for customer evaluation. The construction teams were organized around actor roles. A "daily build" process was started with these iterations. System integration was not a difficulty at the end of either of these iterations. The customer evaluated the prototype at the end of the first semester. The second course began with consideration of the customer response to the prototype - a mini-elaboration iteration using the same teams as Construction 2. This gave the students a good introduction to feature creep. The deliverables were minor revisions to some use case documents and the vision document, and revision of the Rose model. Construction 3 and 4 were to deliver the final product. The team structure was changed to reflect the functional organization of the Rose model. Code from the prototype was evaluated from a reuse viewpoint and reorganized around functions (e.g., several actors needed to write reports, hence the prototype contained several ways to write a report; the best version was used in the final construction). Construction 3 and 4 continued the daily build process for the DLL - 90 builds were completed. Transition consisted of a public presentation of the project to the customer, completion of the documentation (on-line and hard copy) and construction of a web site and database load for beta testing by the customer. At this point the students were "promoted" in the workplace role to "managers". Now is the time to begin the Inception and Elaboration for the next-year's project after the students have been through their "training component" and functioned at the "analyst" level in a project. Ratint of the impact of the project course on the market value of graduates: Time will tell. Those students currently working in the field have found previous versions of the course very realistic and very helpful in their current jobs. The new graduates will be tasked to "report back" after they have had on-the-job experience. ###################################################################### Title: An Undergraduate Software Engineering Project Course at UCSC Authors: Donna Stidolph and Linda Werner [linda@cse.ucsc.edu] Donna Stidolph (Graduate Student and Teaching Assistant) and Linda Werner (Lecturer in Computer Science and Computer Engineering) Institution: University of California at Santa Cruz Summary Page: Projects are formulated and conducted by a small number of faculty members specializing in Software Engineering, with faculty members and teaching assistants supervising student teams. The project course is taught at the undergraduate level. The objectives of our project course are - degree accreditation concerns - to better prepare students for industrial projects, - to develop ability to work in a team - to enhance communication skills and writing skills - to enhance project planning skills. Our project course is offered in the following degree programs: bachelor of science in computer science, bachelor of art in computer science, bachelor of science in computer engineering, and bachelor of science in information systems management. The project workload is part of a general software engineering course. Our courses are 10 weeks long with 3 1/2 lectures hours per week. The rating of the impact of the project course on the market value of our graduates is 4 on a scale of 1(low) to 5(very high). Detailed Description: The Software Methodology course at UC Santa Cruz is a ten week project course for seniors majoring in Computer Science, Information Systems Management or Computer Engineering. Our goals are to enhance students' ability to succeed in industry by introducing them to the theory and practice of software engineering. To teach students about the practice, we give them experience working in groups and working within an externally imposed process. The emphasis in the course is on the non-coding aspects of the software engineering process. Students are formed into three to five person groups during the first week of class. The groups then select a game to re-implement on a computer, following a design/production process that we define. The students are required to submit the following deliverables: a requirements specification, a user manual, a paper prototype, an architectural design, a detailed design, white box test procedures, commented code with a coding standard, a functional system test plan and procedure, and a formal Test Report. The goal of the project documentation is to provide a consistent and accurate view of the project across time. This means that all documents are traced back to the preceding document, that the project is sold off to the requirements documents, not the design documents, and that multiple revisions of the documents are required. Time, even more than is usually the case, is the major challenge to making this class effective. Because of the ten week schedule, both group and project selection must be done the first week of class. In order to streamline group formation, at the first meeting, after a brief introduction to the class, we have an "ice breaker" exercise. The students form impromptu groups and assign a time keeper, note taker, moderator. They then gather several pieces of information about each group member: name, major, and skills/courses/work experience of each person. The group then tries to assess together what skills are needed for this class (tech writing, GUI coding, etc.) and which of those skills are missing from the group as it currently exists. This exercise helps students get to know one another both on a personal level and on a professional level, and it gives them practice running meetings - something that they will be doing a lot of during the rest of the quarter. After having them consider these things as a group, the students fill out "getting to know you" forms, in which they state their major, GPA, programming languages, whether they've had any technical writing classes, and who they would like to work with. We, the professor and TAs, then form the groups. If people elect to work with one another, we always allow it. However, the intent is that the pre-questionnaire exercise allowed the students to think about what they are getting into, so that teams can be formed based on skill sets rather than (or in addition to) friendships. Once in groups, the students start project selection. We encourage Them to select a simple game as a project. The overwhelming advantage Of games is that the students can usually find one game that they have all played and for which they can all agree on a set of rules, thus reducing start-up frustration to a level that can be tolerated in a ten week class. Groups frequently select games too complex for the time, or too Simple to support the weight of the documentation we're going to pile on top of it. To address this problem, we require the students to have both defining and distinguishing attributes for their games. "Defining" attributes are those behaviors without which you haven't done what you set out to do - a checkers game without crowning, for example. "Distinguishing" attributes are what sets apart this particular implementation of the game: an AI engine for a computer opponent, or a history of high points players. The students are directed to design so that all the attributes could be addressed, but the game will be functional with only the defining attributes implemented; that is, no defining attribute can depend on any distinguishing attribute. Thanks to Brian Lawrence of Coyote Software for the use of his requirements templates, which encourage the prioritization of requirements. We work with the groups to make sure that the overly ambitious groups have a manageable set of requirements in their defining attributes; and that the under-ambitious groups have several scope-extending requirements in their distinguishing attributes. This has two advantages. First, this allows requirements adjustments without documentation rewrites, only negotiation. Second, it causes them to think about what the fundamental requirements for the game really are - good practice for the real world. In the case of the under-ambitious groups, the "distinguishing" attributes become a list of requirements enhancements we can levy on them if, later in the quarter, we feel that they've bit off less than they can chew. (We have done this as late as two weeks before system test. Rather than change their functional test documentation, which only addressed what they had planned to do, the students wrote an Engineering Change Proposal, identifying areas of change in the design and test documentation, reasons for the change, etc. After games and groups are selected, the groups are given a week to get organized. After that, milestones are due at a rate of one per week until the sell-off demo on the last day of class. Each group is required to have a notebook containing all the project documentation, including group time logs and meeting agendas/minutes, and the entire notebook is submitted for each milestone, so consistency checks can be made. To support this production rate, in addition to covering the topics In class, templates for, and samples of, the documents are placed on the class web site, and the grading sheets that the TAs use are made available to the students to guide them in how to invest their effort. Since a premium is put on consistency but we want the documents to reflect reality, we do not require that the students print out a new version each time a document changes; we have implemented "redline" control of the documents. In this scheme, documents can be changed by hand-writing the change in the original document in ink, initialing and dating the redline, and noting the change in the change log at the beginning of each document. When the document becomes unreadable (TA's decision), the updates are made as a batch and a new version of the document is released. Inspection techniques are covered within the first week, before the first milestone is due. As soon as that lecture is done, one group per class meeting performs an inspection of their current milestone document for the class, for a significant portion of their grade. In addition to the milestone documents, there is an individual homework assignment each week, but it's simple. On the first day of class, the students are given ten minutes to answer the following question: "You've been at your current job for a week. Your boss has just filled you in on what you're going to be doing - your job is, according to him, to "improve" the GUI of the current product. He tells you that the person you replaced had been working on it for awhile, but just couldn't seem to get it right. The woman in the cubicle next to yours tells you that the guy quit just before he got fired, and you are the third person hired to make this 'improvement'. What do you do? (Quitting is not an option - you love the espresso machine.) Use your knowledge of software engineering tools and techniques to guide you." Each week, each student is asked to take ten minutes and answer the question again, in light of what they learned the previous week. The most frequent problem we've encountered is group grading. There Is only one individually graded milestone, all the others are group efforts, and every quarter there is a group that has problems with equitable distribution of work or effort. Most groups ask the TAs or the professor to help them work through the problems, but we also offer an alternative grading scheme. Unless otherwise directed, all group members get the same score on all milestones. However, as an alternative, group members can submit "votes" on how much each member contributed. We take that input and average it with all the other inputs (assumed to be equal if people don't vote) and use that to allocate the individual scores. Since it is an average, one disgruntled group member can't move the numbers very much, but if two or three people feel someone is taking advantage, they can affect the grade significantly. We are a relatively small engineering school and we only allow seniors in the class. As a result, it's not unusual, at some point in the quarter, to have all the members of a group working on a project for another class. Since we are a time sink for the entire quarter, we feel that we should provide the flexibility so that this isn't catastrophic. Each group is allowed to submit one milestone up to a week late with no penalty, but they must tell us three days in advance. This has no effect on the next due date for the next milestone - they'll have to submit two the following week, but it gives the students some control over their time and doesn't force them to make an either/or choice about what project to do. Students come to the class with differing levels of preparation. We attempt to combat this by pointing out the skill sets needed for a group to succeed. Frequently, though, the problems are caused by inexperience in time budgeting with group projects, not by any lack of technical skill. On average, one group a quarter gets into trouble. If the class size supports it, the TAs can intervene by working through the next milestone with the team, by requiring daily status reports via e-mail, etc. However, not all problems can be addressed. Plans for the future include requiring a section for upward compatibility with a "Common Game Manager" for all the games. At the requirements level this would require all the groups agree on a common user interface standard, so the games all looked the same; and that they select some method to ensure that the games can be integrated: common language, common IDE, etc. Linda Werner, Ph.D., Lecturer 831 459 4953 (w) 831 427 2076 (h) 831 459 4829 (FAX) Computer Science and Computer Engineering Departments 157C Baskin Engineering University of California, Santa Cruz, CA 95064 http://www.cse.ucsc.edu/~linda ###################################################################### Title: A Software Project Course at Norwegian University of Science and Technology Author: Letizia Jaccheri letizia@idi.ntnu.no Institution: Department of Computer and Information Science, Norwegian University of Science and Technology, Trondheim Norway Summary Page: The type of your project course: 1. Industry involvement: no 2. Projects proposed and supervised by faculty members in areas of their expertise: no 3. Project(s) formulated and conducted by a small number of faculty members specializing in Software Engineering, with faculty members and teaching assistants supervising student teams: yes 4. Other: please describe The project course is taught at: 1. undergraduate level: yes 4th year 2. graduate level: yes, graduate students may choose this course as well. The objectives of the project course: - better prepare students for industrial projects, - develop ability to work in a team, - enhance communication skills and writing skills, - enhance project planning skills, - other objectives - experience the difficulty of changing existing systems, experiment with architecture issues, work with alternative designs for the same system. Project course is offered in the: 1. general Computer Science degree: yes, all students can choose it. 2. Software Engineering degree: yes, it is mandatory for software engineering students. 3. other - please indicate. Project workload: 1. project is a part of a general Software Engineering course: yes. The project has a workload equivalent to 1/2 of a full-fledged project course. 2. full-fledged project course with workload equivalent to: for example, a typical 1 term course (13 weeks, 3 lectures per week) Rating of the impact of the project course on the market value of Graduates(1-low to 5-very high): 4 Detailed Description: I have been teaching for the first time a course in the field of software architecture during Spring 2001. The educational goals of the course are the following. First, let students get acquainted with methods about architecture evaluation and change, software design styles and patterns, and domain specific architecture. Second, students must experiment with architecture issues, e.g., evaluate and choose alternative designs for the same system, apply patterns, and above all, experience the difficulty of changing software rather than build it from scratch. The course is built around a project. Concerning the industrial involvement in the project, I designed a project which emphasizes application of best practices and principles in the field of software architecture without any emulation of real-world (hilburn2001). The only involvement of real world actors consists of three guest lectures from industry. In fact, students which attend this course, have experienced during the previous semester a big project course which has the main goal of letting them experience the interaction with a real customer. So, it is a choice to create an environment in which students concentrate mainly on architecture issues. The project process definition and rules are simple. Input to the project are existing methods and tools for deriving architectures from requirements (such as RUP and rational rose), methods and tools for architecture analysis and transformation (Bosch2000), and the eCourse system. eCourse (ecourse2001) is a running support system for document exchange as BSCW (bscw2001) which has been developed before course start and which comes together with its requirements, architecture, design, source code, and test, etc. eCourse is a small system (100 classes and 6000 lines of Java code). Students view the system eCourse both from a developer and a user perspective. Students will implement both changes to improve the architecture with respect to quality attributes (maintenance, performance, usability) and maintenance changes. Every student will use eCourse to access and exchange documentation. Documentation includes slides from the teacher, all documentation about eCourse itself (requirement, design, etc.) and its subsequent versions. There are 10 groups, each group having 6/7 students. The maintenance group is responsible for correcting major bugs, as well as evaluating if and which subsequent versions of the system shall be taken in use This group will be stable over the whole semester. Then, we have 3 test groups, 3 architecture groups, and 3 implementation groups. The test groups are responsible of both improving requirements and evaluating architecture and testing the final systems. The architect groups are responsible of transforming the architecture. The Implementation groups will change the code. For each phase, there is one group who is in charge of working with performance, one group who works with maintenance and one with usability. We could have chosen other qualities such as reliability, safety, and security. Our choice is pragmatic and we may choose other quality attribute combinations in future runs of the course. Each phase lasts three weeks, so the project spans over the whole 13 weeks semester. Here, for each phase, we list phase name; responsible group; and deliverables: * Improve requirements and Evaluate architecture; Test group; Scenarios for non functional requirement and Architecture evaluation. * Transform architecture; Architect group; New architecture, new Rose models. * Change implementation; Implementation group; New system. * Test; Test group; Test report. * Maintenance; Maintenance group; Change report. All documents are delivered using eCourse. Each deliverable contains a small evaluation of the phase and reports about how much time was spent. Each deadline is associated to a one hour presentation in classroom per group. We are now in the process of analyzing project data to assess our pedagogical and research goals. Students have been working hard. The presentations and discussions in class have been interesting for both students and teachers. Students have reported a total amount of 1161 worked hours. This time effort has been divided as follows: 250 hours for Improve requirements and Evaluate architecture; 423 hours for Transform architecture; 305 hours for Implementation; 183 hours for Test. References: (Bosch2000) Design & Use of Software Architecture, Jan Bosch, 2000, Addison Wesley. (eCourse2001) The eCourse system, ada11.idi.ntnu.no/ecourse.html, (In Norwegian). (bscw2001) BSCW (Basic Support for Cooperative Work) home page, http://bscw.gmd.de/ (hilburn2001) So Let's Make That Software Project Course Real World, Tom Hilburn, FASE April 2001. ###################################################################### Title: A Software Engineering Project Course at the University of Texas at Austin Author: Vicki L. Almstrum [almstrum@cs.utexas.edu] Institution: Department of Computer Sciences, Univ. of Texas at Austin Summary Page: The type of your project course: Projects formulated by instructor in collaboration with "clients" in the community and in other parts of the university. Teams supervised by instructor and teaching assistants, with participation by up to two mentors from industry per 5/6 person team. There are 10 to 15 teams per semester. The project course is taught at: 1. undergraduate level The objectives of the project course: - better prepare students for industrial projects, - develop ability to work in a team, - enhance communication skills and writing skills, - enhance project planning skills, Project course is offered in the: 1. general Computer Science degree (as an elective) Project workload: 1. project is a part of a general Software Engineering course Rating of the impact of the project course on the market value of Your graduates (1-low to 5-very high): 4 - high Detailed Description: This past academic year was the fourth year I have taught this Software engineering course. Enrollment this spring semester was 88 Students across three sections. The practical side of the course Emphasizes creating genuine projects for real clients. Full information about the course can be viewed via the URL http://www.cs.utexas.edu/users/almstrum/classes/cs373/. I have also described the course in the article "A Course with Service-Oriented Project Work" (FASE, August 1999). In the remainder of this article, I discuss a number of issues that illustrate how I try to make this course realistic. I feel it is vital to incorporate real world experiences. Every team works with a real client and must communicate directly with the client to understand the true requirements. Every team produces a series of documents that must meet the class documentation standards, which are based on industry standards. I match each team with up to two outside mentors, professionals from industry who advise the team and provide comments on the team's work products. Students may not enroll in this course until they have completed the Core courses in the CS curriculum. Most are seniors, with the most of the rest juniors and an occasional graduate student. As part of becoming acquainted, the teams must assess their own skill sets. Once assigned a project, each team must plan for how to acquire any additional technical skills they will need for their projects. During some in-class lectures, we discuss key commands for using Unix, CVS, and other development tools. The teaching assistants for the course lead discussion sections early in the semester, where they give more detailed presentations of the commonly used support tools. The class web site includes links to on-line resources, which assists students in discovering some of their own answers from among options that have been used in earlier semesters. Because this course is a substantial writing component, I assign individual writing exercises where each student develops his or her personal writing ability. The teams' project documents are not appropriate for individual evaluation because I give each team freedom to delegate tasks as they prefer. In one of the individual writing assignments, each student reviews two projects from earlier semesters (as assigned by me) and writes a report based on their findings. The students complete this assignment early in the semester, which helps them become familiar with the general structure of these projects much sooner than they otherwise would. The students' results also provide feedback on needed improvements for these older projects. In order of occurrence of initial versions, the main project Milestones during the semester are: * the Project Bid (the basis for assigning projects to teams; the allocation of projects is competitive and no two teams work on exactly the same project; some projects are new developments and some are extensions of projects from earlier semesters) * the Project Plan (an initial snapshot of the team composition, plan for approaching the project, team procedures, etc.) * Software Requirements Specification * Preliminary Software Design Specification * Mid-semester in-class presentation of team and project (done in a professional setting using computer and projection device; all students comment on sticky notes as each team presents; the notes are stuck onto team-wise posters on the wall as everyone leaves and the posters taken immediately by the teams; the instructor scribbles observations on a prepared rubric in order to give very quick and somewhat detailed comments to each team) * Detailed Software Design Specification * Mid-term mutual evaluation (each team member evaluates everyone on the team, including them self; the results go only to the instructor, who returns individual summaries and suggestions for improvement to each team member) * Verification and Validation Plan * Alpha version of project, with audit of the project by the teaching assistant (and verification by the instructor) * Verification and Validation Results * Beta version of project, with audit of the project by the teaching assistant (and verification by the instructor) * Final in-class presentation of project (similar to the mid- semester in-class presentation, except most teams now demo their nearly completed projects) * Final version of project * Client Release Presentation (at the client site) * Final mutual evaluation (essentially the same as the mid-term version except the results from this version are used to determine 15% of each student's final grade) * Legacy Turn-in Meeting (an hour-long meeting where the team presents the instructor with a notebook that includes final versions of all documents, team reports, and other information that would be useful as a future team begins to understand the project for modifying or extending it; the team leaves the meeting with a list of action items to complete in order to finalize the project) While the schedule of milestones is pre-defined, I remain very flexible in allowing teams to slip most milestones. They must request the slip formally (via email), they must motivate the slip, and they must assure me that the slip will not adversely affect the remaining milestones. I generally grant all requests for slips. Essentially every document is submitted at least twice. I do not always find the time to return feedback on later versions of the documents but expect that the mentors will continue to review all versions for content and consistency. This course is very demanding of the instructor and teaching assistants. We divide the evaluation tasks to the extent we can. I personally provide detailed feedback on each team's initial version documents and, as time allows, on later version documents as well. In my comments, I emphasize the importance of following standards and interpreting the various sections in a way that is consistent with intentions. Each teaching assistant is associated with a specific section of the class, which allows him or her to focus on a maximum of five teams. The teaching assistants meet with each team at least three times through the semester; the agenda of the meeting is set by the team to make the time as useful as possible. When the teams turn in the alpha and beta versions of their projects in the latter part of the semester, the TAs conduct an audit of their teams' projects, using a pre-published checklist of concerns that address how well the project conforms to standards and whether the product runs well. I meet with teams during in-class meetings periodically during the semester; these brief meetings help me assess how each team is doing. The key meeting between me and the teams is at the end of the semester, during which the team turns in their legacy notebook. Together, we walk through their collection of materials about the project, assigning action items to complete in order to finalize the project before transfer to me. During the meeting, we use a projection device connected to a computer linked into the departmental network, which makes it possible to inspect the team's final repository and make quick adjustments and corrections on the spot. Teaching this course has been very rewarding. Through regular Individual journal entries (about four per semester), I receive a great deal of feedback from students. This feedback helps me adjust the course both during the semester and between semesters. The feedback also helps keep me energized, as I quickly see the effect of what I am doing. The course has the reputation among the students as one that requires hard work but provides excellent return on that investment; they like seeing software engineering from both the theoretical and the practical side. Balancing these factors in setting up the course is a tricky task. Two approaches we have considered to improving the work load of the course for everyone would be to either make it a two-semester sequence (first semester: theory plus writing component; second semester project-focused) OR do away with the writing component aspect (and thus remove the need for carefully evaluated individual assignments). At this point, no such modifications are imminent. Vicki L. Almstrum, Ph.D tel: +1-512-471-9737 Dept of CS, TAY 2.124 (C0500) +1-512-471-7316 (dept. switchboard) Univ. of Texas at Austin fax: +1-512-471-8885 Austin, TX 78712 USA email: almstrum@cs.utexas.edu office: TAY 4.118 http://www.cs.utexas.edu/users/almstrum/ ###################################################################### Title: Real Software Engineering Projects at the University of Sheffield Author: Mike Holcombe [m.holcombe@dcs.shef.ac.uk] Professor of Computer Science and Dean of Engineering University of Sheffield INTRODUCTION Teaching computer science and software engineering students is greatly enhanced if they can be introduced to the real issues relating to software design through the mechanism of projects for real business clients. For more than 10 years we have required students to take part in team projects in their second year where the teams compete with each other to produce a solution for a business person's current problem. Each student is required to work for 100 hours on this project during the semester. This equates to 9-10 hours per week on the project for each student over 12 weeks. Typically there are 80 students in the class and there are three business clients each with a specific problem relating to their business. The student teams are each allocated to one of these clients. The teams comprise 5 students and each client deals with 5 or 6 teams. At the end of the Semester the client evaluates all of the software solutions produced and selects the best one for use in their organisation. The winning students receive a prize. This framework really transforms the students' learning because it emphasizes two of the most problematical issues when teaching software design, how to communicate with a client and capture the real requirements and how to deliver a really high quality, bug free system. It is very hard to introduce either of these dimensions into the curriculum using projects specified by academics. Students know that once the software has been marked it is usually thrown away. With our approach, which we call the Software Hut, students are much more motivated because they know that someone wants their work and will use it. They also learn quite a lot about the way businesses work. It is always the most popular course and the one that they say teaches them the most! More details can be found in [1] and [3]. A recent extension of this approach occurs in the 4th year where the students run their own software company and spend approximately one third of their time working in it. The company, they call it Genesys Solutions, [2] and [4] (formerly called VICI), has a wide variety of clients requiring database systems and e-commerce applications. About 25 students work in the company. The students run the company, take all major decisions, operate their own premises and network, and carry out R & D as well as specific industrial projects. As part of this the students negotiate the details of a contract with a client - cost, delivery as well as the detailed requirements specification. As one might expect, estimation and planning is a major issue in running the company and one of things that we are trying to do is to collect suitable data on projects that would help us to do this better. We believe that this student-run company is a unique innovation but one which the students are incredibly enthusiastic about. As an aside, a number of former members of this company have successfully set up their own real software houses. THE SOFTWARE HUT I introduced the Software Hut course 12 years ago, it was completely novel, no other courses like it were being taught in the UK. It introduced second year students to a realistic experience of working in a software house. It was different to all other courses because it involved a real external client who wanted software solution to a real business problem. This introduced students to two fundamental issues that cannot be addressed in any other way: 1. the problems of negotiating with a client who may not know what they really want, 2. the responsibilities of producing a high quality solution that can be used successfully in the client's business. These issues are at the heart of software engineering and are rarely dealt with satisfactorily in the theoretical confines of a computer science course. Of course, some universities encourage or require students to take placements in industry, this is sometime valuable but the experience can be very varied and may still not address the fundamental two points identified above. All the research we have carried out clearly indicates that the in-house (i.e. on campus) real client experience is the best learning environment since we can ensure that the very best and latest professional practice is experienced by the students, something that would not be the case in many industrial placements. As I will indicate later this experience develops students skills and understanding in a way that is demonstrably superior to that provided by standard curriculum Computer Science found at ALL other UK universities. The Software Hut comprises around 90 trainee software engineers and three senior managers. Typically it produces three real systems each year for real clients from business companies and other, public, organisations. The core business expertise of the company is bespoke databases with custom front ends and web based applications, usually with an e-commerce aspect. The mode of operation of the company is to have one third of the members working with each client. Within this division into sections there are 6 teams of 5 developers each of which build a version of the product in competition with the others. The clients choose the best system from the 6 produced and these are used in the client's organisation. The IPR is negotiated separately for a fee. What this means is that there is an opportunity to use different design approaches with the different teams and this can be the basis of a detailed scientific comparison of different approaches. Currently the company is planning to operate with the next projects an experiment whereby one set of teams applies "standard" software engineering methods based around UML and a significant design and analysis phase. The other set of teams will use the extreme programming approach - a lightweight, test driven approach. We hope to collect and analyse some data from this exercise to see if there is a significant difference in the performance of the teams and the quality of their products. GENESYS SOLUTIONS With the assistance of the FDTL grant I introduced the 4th year Student software company as a natural development of the 2nd year Software Hut. Here the students own and run the company, doing real Projects for their clients and using their own premises that I arranged for them. This is the Business Incubation Laboratory, which is completely managed by the students,. They purchase their equipment from their earnings and install and administer it all, it is run independently of the University, the students are fully responsible and as such have developed a highly professional infrastructure and arrangements which would be a credit to any major software company. Genesys Solutions is a partnership of 25 qualified software engineers carrying out a similar range of contracts but also providing consultancy and other services. The company has its own R & D section and provides infrastructure support to the design process. The way that this company will be used will be to consider how the results of the comparative evaluations of the methodologies and processes derived from the Software Hut experiments can be introduced and embedded into an existing software house. This is an important area because of the apparent reluctance of many software companies to introduce new methods of working. All clients of these companies will be asked to permit the results of these experiments to be published. In the past a number of the projects carried out by these companies have been the basis of publications and so far all the clients have been happy with this - provided any "in confidence" commercial details are hidden. It is very difficult to persuade software houses to release the results of any analysis of their design projects because of commercial reasons. THE SOFTWARE OBSERVATORY Since software development is a rapidly changing industry the introduction of new methods, tools and languages is likely to continue, we need a mechanism for evaluating the latest ideas in realistic situations. I have developed the two activities, the Software Hut and Genesys Solutions into a framework for research into empirical software engineering which I am calling the Software Engineering Observatory. The aim of this is to use the activities of these students projects as a basis for fundamental research into the construction of software and to provide insights into how it might be done better for the benefit of the software engineering industry. This is an example of teaching activities supporting subject based research. Once the observatory has been established it will be able to provide a service to the software industry based around realistic and rigorous scientific approaches to the evaluation of different methodologies and processes over a long term. The Observatory will be reactive to new methods and technologies and receptive to new demands from clients. The students involved will benefit from exposure to the latest ideas and will feel part of an important contribution to the improvement of their subject. During the course of the Software Hut projects each team generates between 200 and 300 pages of documentation, this includes requirements documentation, detailed designs, source code, test sets and results, debugging reports, quality review reports, time sheets, meeting minutes and team evaluations. The source code is typically of the order of 10 000 lines of code for the sort of systems built. The clients and managers also produce reports on the products delivered and evaluated as well as the judgments on the design processes. This documentation, taken over 18 teams and archived over several years so far, provides us with a major resource for the analysis of many aspects of the investigation. This is how the work leads into real research into empirical software engineering. AN EXAMPLE The Observatory team will define a number of experiments each year based around the use of the Software Hut and Genesys Solutions projects. These experiments will be carefully designed and suitable clients and projects obtained to act as the focus of the experiments. The framework and facilities required will be set up by the Observatory team, this will include suitable tools, repositories and appropriate recording software and techniques. The definition of the metrics and other evaluation techniques that are to be used will be done before the experiments begin. The training of the student teams in the appropriate technology and facilities will be carried out under carefully controlled conditions. Since all clients pay for their solutions there is an important motivational driver for the student teams and this has always ensured that the teams are appropriately motivated. Key activities will include the estimation by the teams of the resources needed for their projects and this will be done using appropriate methods - in fact estimation techniques could be a particular focus of some experiments as well as risk analysis and planning techniques. Other suitable metrics such as object point analysis, weighted methods per class, as well as measures of software quality will be available. The time spent per team, per team member and how it is spent are also important factors that will assist in the analysis of the efficacy and expense of any method. The relationships between all these variables will be major areas of interest. This semester (February 2001) sees the start of the next Software Hut exercise. There are, as usual 3 clients each dealing with 6 teams and what we plan to do is to divide the 6 teams into two groups, one of which will be given some reinforcement in traditional software design techniques and the other will get a crash course in Extreme Programming. We will then monitor the progress of the two cohorts of students, some using XP others not, as they attempt to build their solutions. This will be done by studying the way they manage their projects. Each team has to produce and maintain realistic plans, keep minutes of all their project meetings, and by interviewing them weekly. We will also get all of their working documents, requirements documents, analysis, test cases, designs, code and test reports. These will provide many further opportunities for measuring attributes of their output, ranging from function and object point analysis to bug densities. At the end of the Semester, the clients evaluate and mark all the Delivered solutions, they use a structured marking scheme that we construct for them and this provides a final level of measurement relating to how well the solutions did - usability, installability, functionality, robustness etc. These are the key attributes since they will be applicable to all the solutions no matter how built. We will use this information in a statistical analysis to see whether there are any significant differences in the quality of the final products between XP and traditional "heavyweight" methods. Finally we will require each student to give both a team evaluation and a personal commentary on how the project went, the strengths and weakness of what they did and how they did it. In the past this has proved to be very useful in identifying issues and problems with approaches to software development. After delivery we will be able to track the performance of the delivered systems to gain further information about their quality in their working environment. The three clients are as follows (see Figure 1.): Client A is a small start up company in the Bioinformatics industry requiring software for data analysis. Client B is a legal practice centre, that requires computer based training software for the legal profession. Client C is an organisation which brokers waste and wants a web based system that interfaces to the existing database and allows clients the opportunity to browse the database. This is just the start. We are bound to see, as software engineering evolves, the emergence of different ways of doing it, using different tools, methods and notations. This will give us further opportunities to test out the ideas in our Software Engineering Observatory: the Software Hut for detailed comparative experiments and Genesys where we are investigating how new ideas and methods can be introduced into a working software company. EVALUATION AND DISCUSSION One of the most important results from the work that has been done so far is the reaction of both the students involved and of employers. It has been entirely positive, we always ask each student to write a reflective self evaluation of their experience in both the Software Hut and Genesys. These always emphasis how valuable the experience as been and how it has developed a great awareness of the industrial context of software engineering, how it has put into perspective much of the work that they have covered in other courses and how it has given them a lot of self confidence and the skills to work in a high quality professional design environment. The fact that they have to document their work, their meetings and the time that they spend carefully and in a standardised format has helped them to adjust from the rather chaotic and disorganised atmosphere of university student life to one of an enthusiastic and highly organised professional. very student remarks that at interviews these courses are the only ones that the companies want to talk about, they are often amazed at what the students have achieved. This is confirmed by our own interactions with employers through the Department's Industrial Liaison Board and on other occasions. Many of the top employers are now targeting the Department because of its reputation. In the Software Consultancy business, for example, the principal focus of graduate training programmes is the relationships with the clients. This is something that my students have been heavily involved with, unlike any other university graduate! They thus have a major advantage over their competitors. Every year I carry out an in depth interview with each member of Genesys just after the end of the 1st Semester. This is essentially formative but it also allows me to assess the way the course works at the half way stage. This year the class consists of 15 MEng students, (4th year students who have spent the previous 3 years in the Department, these students have done the Software Hut in their 2nd year); and 10 advanced MSc students, who have graduated with good Computing degrees from other universities. None of these MSc students have done anything like the Software Hut, some have done group software design projects but all have commented that these were not taken seriously. The contrast between the two cohorts is nothing short of staggering. The MSc students have found it very hard adjusting to the fact that they have much more responsibility for their own learning and for the management of their projects. None had ever met a client before and were extremely nervous about the prospect. None had really had to manage a serious group project before, either. There was a very marked difference in the attitudes when it came to the need to learn some new technology, the Sheffield students immediately got on with it and helped each other to master the complexities of the material whereas the MSc students immediate response was to ask for courses in the material. Their ability to direct their own learning was not very impressive. Luckily, the Sheffield students were able to help them by giving them short courses in the material. The Sheffield students also insisted on wanting to run the company themselves, taking full responsibility for all decisions and for managing their projects, the MSc students, on the other hand, wanted much closer management from me and my colleague, telling them what to do to a much greater extent. This seems to be impressive evidence that the Software Hut is extremely successful in developing the lifelong learning skills and confidence that are needed in such a dynamic business as the software industry. The question remains of why these approaches are so unique, they have received a considerable amount of publicity in the national computing press and at many conferences and workshops. The only UK universities where anything like the Software Hut has been introduced are Leeds and Leicester who both started up a second year group project modelled on it last year 1999-2000, although neither have real clients, the lecturer running the module is the client, a factor that I believe seriously weakens the exercise but may be an interim feature. Whenever these courses are discussed at meetings the standard response of academics who would like to set one up is that it would not get through their quality assurance process. They say that concerns about the control of the outcomes, the assessment process and similar issues would prevent their receiving approval. This is just one example of the way that fear of the QAA assessment process has prevented truly innovative developments in teaching and is to be thoroughly deprecated. The unpredictable attitudes of QAA assessors is the main reason for this problem, although the recent accreditation by the British Computer Society of the Department's degrees was extremely favourable and great praise was made of both the Software Hut and Genesys, so perhaps times and attitudes are changing. The reasons why both Leeds and Leicester have developed their courses, despite these fears, might be related to the fact that I am currently their external examiner! References 1. A. Stratton, M. Holcombe and P. Croll "Improving the quality of software engineering courses through university based industrial projects." in "Projects in the Computing Curriculum", (eds.) M. Holcombe, A. Stratton, S. Fincher, G. Griffiths, Springer, (1998). 47-69. 2. M. Holcombe and A. Stratton. "VICI: experiences and proposals for student run software companies." in "Projects in the Computing Curriculum", (eds.) M. Holcombe, A. Stratton, S. Fincher, G. Griffiths, Springer, 103-114. 3. with Helen Parker, "Keeping our customers happy: Myths and management Issues in Client led student software projects." Computer Science Education, 9 (3), 230-241, 1999. 4. Genesys Solutions Web site, On-Line at ###################################################################### Title: Software Engineering Project Course at Gannon University Author: Steve Frezza [frezza@gannon.edu] Institution: Gannon University The type of your project course: 1. Industry involvement: NO (not typically) 4. Other: please describe Projects formulated by students, directed by students under faculty supervision The project course is taught at: 1. undergraduate level The objectives of the project course: - better prepare students for industrial projects, - develop ability to work in a team, - enhance communication skills and writing skills, - enhance project planning skills, - Enhance project specification skills Project course is offered in the: - general Computer Science degree - Electrical Engineering (Embedded Software Engineering Track) Project workload: - project is a part of a general Software Engineering course Rating of the impact of the project course on the market value of Graduates (1-low to 5-very high): 4 - Moderately High (SWAG, based on oral feedback from students and their job hunting) Two issues we've attempted to address in our undergraduate Software Engineering project course are the issues of student motivation and team formation. While the projects are structured to walk students through the process of formulating, designing, implementing, testing and delivering a product, these are relatively difficult issues to manage without attaining strong student commitment to the projects themselves. In particular, students have little experience formulating problems for others to solve. Our method for encouraging high levels of student motivation include a competitive proposal process that allows students to competitively propose ideas (scoped to fit within the bounds of the course), and to form teams around the projects based on their interests. These projects and teams are scoped to be small (2-4 students) to ensure the ability of the students to deliver their project at the end of the semester. The caveat to the proposal/team formation process is that students are not allowed to work on projects they personally proposed: thus the students of one team are organized to be the functional owners (customers) for another team. Thus they serve as interested (and more importantly _available_) customers who do not always have clear ideas of what they want in their product. Since it is a team of functional owners, there are ample opportunities for real miscommunication among the requirements stakeholders. This means the development team is necessarily faced with the issues of requirements change, ambiguity, etc. that are very real, but typically tractable. This course is a follows a design and testing course, so specific areas of focus include requirements, project planning, risk management, estimation, tracking, product quality, teamwork and other social aspects. Stephen T. Frezza, Ph. D. Assistant Professor, Electrical & Computer Engineering 109 University Square, MB 3181 Erie, PA 16541 Voice: 814-871-7563 FAX: 814-871-7616 email: frezza@gannon.edu URL: http://www.ecs.gannon.edu/~frezza ###################################################################### Title: Software Engineering Project Course at California State University, Sacramento Author: Richard H. Thayer [thayer@csus.edu] Institution: Californian State University, Sacramento Summary page: The type of your project course: 1. Industry involvement: yes 2. Projects proposed and supervised by faculty members in areas of their expertise. Yes and no. Groups of student teams are assigned to faculty members. Most of the faculty members are experts in SWE but not necessarily in the application. 3. Project(s) formulated and conducted by a small number of faculty members specializing in Software Engineering, with faculty members supervising student teams. The project course is taught at the undergraduate level The objectives of the project course: - degree accreditation concerns - better prepare students for industrial projects, - develop ability to work in a team, - enhance communication skills and writing skills, - enhance project planning skills, - other objectives - please describe. - Give them some real-world experience to put on their resume - Make contact with industry that might be hiring - Summarize everything they have learned to date The project course is offered in the: - general Computer Science degree Project workload: - full-fledged project course with workload equivalent to: two semesters (15 weeks each) 2 credits per semester ( 1 hr lecture; 3 hour lab) Rating of the impact of the project course on the market value of Graduates (1-low to 5-very high): 5 - very high Richard H. Thayer Professor in Software Engineering Department of Computer Science California State University, Sacramento Sacramento, CA 95819-6021 Home Tel: 916-481-5482 Home Fax: 916-481-8778 ###################################################################### Title: Using Critical Essays in a Project Course Author: Sally Jo Cunningham [Sally.Cunningham@zu.ac.ae] Institution: University of Waikato (New Zealand) Summary page: Industry involvement: yes The project course is taught at undergraduate level. The objectives of the project course - better prepare students for industrial projects, - develop ability to work in a team, - enhance communication skills and writing skills, - enhance project planning skills, Project course is offered in the 'Information Systems' programme of a computer science degree. Project workload: - full-fledged project course with workload equivalent to: one full New Zealand semester course (12 weeks, 4 lecture hours per week) Rating of the impact of the project course on the market value of Graduates (1-low to 5-very high): 5 - very high Detailed Description: I teach a course formally titled 'Information System Development', in which students work in groups of 4-6 to develop a prototype of a system suitable for a local business. Each group works on a different system. The project is the basis for all assessment in the course, and the students within a group receive the same grade for the various 'deliverables' associated with their group's project. There is no test, as the course is designed primarily to support students in applying skills learned (or rather, hopefully learned) in prerequisite courses, rather than to cover new theoretic material. University regulations, however, require that at least 30% of each student's assessed coursework be 'demonstrably the student's own work'. To that end, the students also receive individual grades for essays that they write, critiquing the work of *other* groups. For example, one group deliverable involves designing the user interface for the system. Each person in the course must read through a different group's design description and write a brief (2-4 page) discussion of the good and bad points of that interface. I then xerox the critiques (first covering the name of the author of the essay), and give each group copies of the essays that critique that group's deliverable. I find these critiques to be one of the most valuable parts of the course. The groups benefit from receiving feedback from their fellow students, as well as from myself. The student critiques are generally felt to be very useful in highlighting the successful/unsuccessful portions of the deliverable, and as such are good sources of ideas for improving the group's project. Since each of the groups is working on a different project, the students don't feel that they are in competition with the other groups, and so feel free to share ideas and suggestions. The essay assignment also allows/forces students to closely examine the work of other groups, which gives the students a better idea of the range of quality of student work and the different approaches to presentation issues that exist within that course. ###################################################################### Title: Projects in Real-Time Software Engineering Courses Author: Janusz Zalewski jza@ece.engr.ucf.edu http://www-ece.engr.ucf.edu/~jza/ Institution: Computer Engineering, Univ. of Central Florida Summary Page: The type of the project course: - Projects proposed and supervised by faculty members in areas of their expertise. The project course is taught at the graduate level (3 credit hours) The objectives of the project course: - Offer students an opportunity to apply practical concepts and principles of real-time software development on an industrial scale project. Secondary Objectives: - better prepare students for industrial projects, - develop ability to work in a team, - enhance communication skills and writing skills, Project course is offered in the Computer Engineering Degree with Software Engineering Specialization Project workload: - project is a part of a general Software Engineering course Rating of the impact of the project course on the market value of Graduates (1-low to 5-very high): 5+ - very, very high Recent graduates got employment at Intel, Motorola, Oracle, Microsoft, Lockheed Martin, Siemens, GTE, NASA, etc. Detailed Description: http://reach.ucf.edu/~eel6897/ Janusz Zalewski Computer Engineering University of Central Florida Orlando, FL 328167-2450 1. Objective Offer students an opportunity to apply practical concepts and Principles of real-time software development on an industrial scale project. There are no commercial objectives in this project, only academic. 2. Assumptions 2.1 Industry has its own organizational structure, which is hard to imitate in the academic environment. So no attempt is made to duplicate this structure in the project's framework. Only selected aspects of the industrial scale project are included. 2.2 It is critical to state up-front what industrial aspects are addressed in the project: organization, management, quality assurance, development, maintenance, etc. This particular project addresses Software Development only. 3. Focus Course title: "Software Development for Real-Time Engineering Systems", determines the Real-Time focus. Additional focus is kept on Networking Software to make this project naturally extensible to the next semester course on "Computer Networks Software Design". 4. Emphasis Keeping the objective and focus in sight, the emphasis is on giving students a chance to acquire or enhance Technical Skills (as opposed to management skills). This emphasis determines project's heavy orientation toward the use of software development tools. It's a fact of life that in the development of real-time software for modern applications, the role of automatic software development tools has significantly increased and nearly replaced the use of programming languages. This is due to the complexity of these applications and a growing need to automatize the design process, control the project, generate code, simulate the behavior, evaluate performance, guarantee safety, etc. 5. Project Organization 5.1 Prerequisite Knowledge Minimum: General Software Engineering course or sufficient industrial practice. Previous class in concurrent or multithreaded programming is a big plus. Partially introduced in lectures during this course are: - real-time software architectures - UML notation, with emphasis on statecharts - conceptual understanding of development tools in four aspects: modeling capabilities, tool connectivity, portability of models, and tool fitness into the development cycle. Project domain knowledge has to be studied from documentation provided by instructor. For example, for the Air Traffic Control System, we collected an entire library of documents useful in understanding the domain concepts and problem requirements. 5.2 Staffing This is an elective graduate course offered once per year with Enrollment of 40-50 students. Student population is divided into teams with max. 4 persons per team. Individual work (1-person teams) is also allowed on a case-by-case basis. Under no circumstances more than 4 students can work on a single team (3 is an optimal number). This is because teams greater than 3 members tend to distribute work very unevenly, and some members do not do enough work and do not learn enough. It is also important to realize that students on a team learn from each other and with bigger teams this is less likely to happen, due to decreased communication, schedule conflicts and other interactivity related issues. Another important issue is how to grade individually a piece of work Done by a team. A partial solution to this problem it to request a team to provide data on percentage of the project performed by each team member. The only supervisor is the instructor. There are no Teaching Assistants. 5.3 Schedule This project must lead to an implementation, so all primary Development phases are covered: Specification, Design, Coding and Testing. A sample schedule (for 12-15 Week Semester) looks as follows: Phase 1: Develop Software Requirements Specification (SRS) Step 1: Preliminary SRS Documentation ready - Week 2 Step 2: Presentation in class on SRS - Week 3 Step 3: Deliverable - Final SRS - Week 4 Phase 2: Develop Software Design Description (SDD) Step 1: Preliminary SDD Documentation ready - Week 6 Step 2: Presentation in class on SDD - Week 7 Step 3: Deliverable - Final SDD - Week 8 Phase 3: Develop Implementation (Code and Test) Step 1: Test Plan ready - Week 9 Step 2: Module testing completed - Week 10 Step 3: Integration testing completed - Week 11 Step 4: Demonstration of the entire project - Week 12 Deliverable - User Manual (including Code and Test Results) Phase 4: Maintenance Weeks 13-14 Steps vary depending on team and progress 5.4 Other Issues Format of the documents is prescribed up-front and based on IEEE Standards, however, adjusted to the needs of the academic project. For instance, sample instructions for an Overview (Section 4) of the SRS look as follows: 1) Identify ALL INPUTS (signals, messages, data items, etc.) your Module needs for processing. 2) Identify ALL OUTPUTS (signals, messages, data items, etc.) your Module produces as a result of processing. 3) Identify ALL FUNCTIONS your Module is supposed to perform, that is, apply to INPUTS to produce OUTPUTS. 4) As far as possible, use UML's Use Case diagrams to describe the functionality of your Modeule 5) As far as possible, use UML's Sequence Diagrams, to describe the sequencing and timing behavior of your Module. Level of individual decisions: * Overall real-time software architecture is suggested by instructor. * Implementation language is selected by instructor. * Individual module architecture and detailed design are proposed by students. * High degree of freedom to select tools by students from the list of 10-12 available. 6. Conclusion 6.1 Skills training Since there is heavy orientation on the use of tools, this course may Look like skills training, but it is not. The use of tools is never taught, students master them themselves and apply in the development, replacing paper and pencil, which were the primary and only tools in the past. After all, what is the role of programming languages, aren't they only the tools to illustrate concepts? In modern software development the role of programming languages is being replaced by software tools. 6.2 What distinguishes this course from other approaches to teaching a project course * This project is of significant complexity and we have to take some drastic decisions to scale it down to a size, which is manageable as a class exercise for a 3-month semester. * Most teams work on the same project, developing or maintaining different components. * Project has heavy orientation on the use of automatic development tools. * Software developed in this project is usually used in the following course during next semester. 6.3 What works and what does not work? In my opinion, everything works, provided you have enough time and enough expertise to do it. With these two limitations, the most likely problems come from the following: * inadequate domain knowledge; this may become a serious problem if one cannot approach experts or they are unwilling to respond; we are resolving these issues by collecting sufficient documentation from which requirements can be derived * insufficient tool knowledge; this is less of a problem, because students do not have to be encouraged to learn how to use a tool and dig into its documentation to resolve problems; when technical support needs to be called, then problems arise because vendors, who provide the tools for free or for educational discount are treating us with significantly lower priority * large size of the project; this is resolved by an option of extending the project throughout the next semester course, making it continuous * it is difficult to teach concepts or theory and apply it in practice in the same course with a project of significant complexity. 6.4 Other problems in teaching a project course and solutions * inappropriate supervision and coordination; instructor's task is very difficult, because he has to manage 40-50 person team; because of this load, I do not emphasize enough certain issues, such as different roles of team members, do not require keeping journals (just don't have time to read them), etc. * it is always a significant issue in a project course: how to stick to teaching principles if there is so much development (read: production); this is especially true when one offers an opportunity to use tools * how to address quality issues in a project course; due to time restrictions, I cannot do it completely in the same course; fortunately, I teach another course on Software Quality Assurance, where a particular project like this can be used as a vehicle for quality assessment. 6.5 The impact of the project course on the market value of graduates. The market value of graduates, who know how to use automatic Development tools is tremendous, because employers do not have to make that much investments in their training. But what counts even more, is not only practical knowledge of Specific real-time software development tools. Because students grow in the "tools culture", companies in domains unrelated to real-time software development, such as VHDL design, are happy to hire these students too, since it's clear that a student can easily adjust to a new tool from a different domain. Our recent graduates got employment at Intel, Motorola, Oracle, Microsoft, Lockheed Martin, Siemens, GTE, NASA, and other smaller Software development companies. ###################################################################### Title: Software Engineering Project Course at National University of Singapore Author: Stan Jarzabek (stan@comp.nus.edu.sg) Institution: Department of Computer Science, School of Computing, National University of Singapore (NUS) Summary Page: The type of your project course: Industry involvement: no - Project(s) formulated and conducted by a small number of faculty members specializing in Software Engineering, with faculty members and teaching assistants supervising student teams. The project course is taught at the undergraduate level The objectives of the project course: - better prepare students for industrial projects - develop ability to work in a team - enhance communication skills and writing skills - enhance project planning skills - consolidate and apply in practice software design principles acquired in earlier programming courses Project course is offered in the: - general Computer Science programme Project workload: - full-fledged project course with workload equivalent to two typical one-term courses (2 X 13 weeks) Rating of the impact of the project course on the market value of Graduates (1-low to 5- very high): Too early to rate the impact, we have offered this project course only twice. ------------------------------------------------------------------ Detailed Description: At the National University of Singapore (NUS), we experimented with various approaches to teaching project courses. Although our students do projects that emphasized real world experiences (we have the co-op programme and a university project course emulating real world situation), the industry surveys were consistently signaling the same problems related to weak development and communication skills in team-based, large scale software projects. We tried to address some of the problems with a new project course focusing on application of principles and "best practices" in large-scale team-based development. We offer this new project course in addition to other courses that emphasize real world experiences. MOTIVATION FOR THE NEW SOFTWARE PROJECT COURSE We observed that when exposed to real world pressures, our students did not know how to take advantage of what they learned in earlier programming and software engineering courses. Students tended to perceive principles as obstacles rater than tools that can help in project work. Assignments in programming courses involve small programs, while one can only appreciate the value of principles when it comes to large programs, developed by teams. Therefore, students have little opportunity to observe why we really need modeling, software architecture, interface definitions, separation of concerns, information hiding or a systematic approach to testing. For example, if 1-2 students can develop a program working closely together in a couple of days and the assignment requires them to define an architecture and interfaces, they will do so just to satisfy assignment requirements, not because there is a real need for those artifacts in the context of practical goals. The value of architecture and interfaces only shows in programming-in-the-large, when we need to understand different program parts separately, split the job into tasks that are completed in a fairly independent way and develop a product incrementally rather than in one shot. THE NEW PROJECT COURSE We postulated that there was too a big gap between programming and software engineering courses, in which students learn about "best practices" and principles, and real world projects. We decided to fill this gap with yet another project course that would focus on application of design principles in a large-scale, team-based project. We adopted a rather formal approach to teaching this new project course, with little emphasis on real world experiences such as negotiating requirements with customers. The new course does not replace but complements other project courses we have been offering to our undergraduate students. Improving communication skills is the major concern and focal point in the project course. Both communication with a customer and communication among project team members are important but in this course we focus on the latter. Ability to express solutions at the concept level, to properly document design, code, test plans and other program artifacts, to describe interfaces and to use assertions are all related to communication skills. So is the ability to prepare and conduct team meetings in an effective way. Communication skills integrate essential human and technical aspects of software development. As students do not have enough opportunity to develop communication skills in assignment- based courses, it is the major challenge for the project course to address this issue. We define programming problem and the development process in such a way that students can experiment with a wide range of techniques related to mastering communication skills. We clearly define the project goals in terms of software product qualities such as flexibility or reliability, as well as functionality. Using problem-based learning approach, we show the students benefits of applying principles and "best practices" to achieve project goals. By following and extending examples, students start appreciating the value of principles and get working knowledge of how to apply them in-the-large. We formulate and conduct the course project in such a way that it is impossible for students to achieve project goals unless they follow the path of "best practices" we are showing to them. The incremental development process for the project reflects development practices used in advanced industries, emphasizes the role of software architecture and encourages systematic, well-planed development. CONDUCT OF THE PROJECT COURSE Students do the project in teams of 6, under close supervision of instructors and teaching assistants who share a common vision of the project course objectives and are prepared to guide students through the project to meet the objectives. The project course starts with 8-10 lectures during which the chief instructor motivates the students, explains the programming problem and the development process. Students spend two weeks on problem analysis. At the same time, they develop a throw-away prototype. In the next two weeks, students develop the first sketch of a software architecture. This includes subsystem level decomposition and description of subsystem interfaces. At this point, each team splits into two groups of 3 students. Each group works on a fairly independent subsystem. The subsystems communicate via a non-trivial interface and both groups communicate and refine interface specifications throughout the project. Students develop the project in iterations, incrementally. Each new iteration extends the program implemented in the previous iteration. The iterative development helps students tackle project difficulties one by one, applying principles of separation of concerns, abstraction and refinement Program reliability is emphasized throughout the project. An Important aspect of reliability is comprehensive testing. In the project, we expect program reliability close to industry standards. Students are advised to allocate enough time for test planning and testing, to make unit testing an integral part of development and to do integration testing and system testing at the end of each of the development iterations. Students use a public domain testing tools. We give students a set of course handouts that includes problem description, compendium of recommended software engineering practices for the project, sample solutions illustrating how we expect them to approach design problems and technical tips. A common problem is to find enough faculty members and teaching assistants qualified to do the job. It takes a long time before teaching assistants can provide useful advice to student teams. These problems escalate when the project course is offered to large population of students. At NUS, project course is compulsory for all Computer Science students, around 500 students per year, and is offered in both terms. It is essential that all the supervisors share a common vision of course objectives. To address this problem, we prepared a comprehensive project framework that shortens the learning time before the new instructors and teaching assistants can effectively advice student teams. Before the project course starts, the supervisors study the course materials to get familiar with the programming problem, development process and software and methods to be used in the project. RESULTS SO FAR We see a big difference in the way students deal with team-based software development at the end of the project as compared to their approach at beginning of the course. Students appreciate the role of software architecture, learn how to communicate in terms of interfaces, how to split the project work and document the work products in a clear way, understandable to their team mates. Most of the teams become very much involved in the project and motivated to work hard in order to deliver a quality product. Though in this course we make little effort to emulate real world situations, we believe students learn some essential skills that will help them to deal with real world project challenges in a systematic rather than chaotic way. We also believe that this type of a project course should be a part of the software engineering curriculum to ensure that students get a working knowledge of design principles taught in other courses. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Upcoming Topics ###################################################################### Software Engineering as a Profession in the United Kingdom Guest Editors for this Upcoming Topic: Barrie Thompson and Helen Edwards University of Sunderland barrie.thompson@sunderland.ac.uk, helen.edwards@sunderland.ac.uk For more information on this topic, please contact the guest editors. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Articles ###################################################################### Ideas and Issues in Software Engineering Education Tom Hilburn The May 2001 issue of Computer (vol 34, no 5, pp 28-35) includes an article by Betrand Meyer titled "Software Engineering in the Academy". I recommend it to those that are trying to develop and enhance quality software engineering programs. As an antidote to some of the shortcomings in current software development Meyer proposes five elements for software engineering curricula: 1. principles: lasting concepts that underlie software engineering (e.g. abstraction, information hiding, recursion, reuse, exceptional handling , etc.) 2. practices: problem-solving techniques that good professionals apply consciously and regularly (e.g., configuration management, metrics, documentation, high-level system analysis, etc.) 3. applications: areas of expertise in which the principles and practices find their best expression. 4. tools: state of the art products that facilitate application of software engineering principles and practices. 5. mathematics: the formal basis that makes it possible to understand everything else Although there may be some disagreement with the organization and details of these curriculum elements they provide a nice representation against which one can compare and contrast the goals and design of an existing or proposed software engineering program. Meyer makes several references to David Parnas' paper "Software Engineering Programmes are not Computer Science Programmes" (Annals of Software Engineering, vol. 6, April 1999) Parnas provides a different perspective on software engineering curricula by arguing that computer science provides a scientific and conceptual base for software engineering curricula, but the structure, objectives and activities of such curricula must be similar to the "traditional" engineering programs. If you have not had a chance to look at this, it is important, though controversial, contribution to the debate about software engineering education. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Book Reviews ###################################################################### Title: Software Fundamentals: Collected Papers by David L. Parnas Edited by: Daniel M. Hoffman and David M. Weiss Publisher: Addison-Wesley (http://www.awl.com) ISBN: 0-201-70369-6 Hardcover, 664 pages Reviewed by Don Bagert Surprisingly enough, for all of his pioneering efforts in computer science and software engineering, Dave Parnas has never written a book. Now he has - in a manner of speaking. This book is a compilation of 33 articles by Parnas on a wide range of subjects in software engineering. There are introductions to most of the articles by many of his well-known software engineering colleagues, including Barry Boehm, Victor Basili and Leonard Tripp. The articles are grouped into four parts: description and specification, software design, concurrency and scheduling, and commentary. Parnas provides a new introduction to each of these four sections. The "Commentary" section is where Parnas discusses education and professional issues (among other things), and so is likely to be of the most interest to FASE readers. Among these articles are "The Professional Responsibilities of Software Engineers", "Teaching Programming as Engineering", and "Software Engineering: An Unconsummated Marriage" (as reported in "David Parnas has CACM Column on Software Engineering" in September 1997 FASE). At the end of the book is a bibliography of Parnas' 210 publications, as well as a detailed index (which is often not found in such paper compilations). Parnas is one of the greatest computer scientists and software engineers of our time. He is also a gifted author and speaker, and never afraid to be critical in his commentary when trying to make a point. Some readers will enjoy these commentaries, while others will like the more straightforward research papers on various aspects of software engineering. In other words, there is something here for everyone. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### ICSE Holds Panels on Software Engineering Education, SWEBOK The 23rd International Conference on Software Engineering (ICSE 2001), held in Toronto, Ontario, Canada on 12-19 May, contained several items of interest concerning software engineering education and professional issues. The first was a panel on software engineering education held as part of the David L. Parnas Symposium, honoring the software engineering pioneer on the occasion of both his 60th birthday and the publication of his first book (see separate article for a review of it). Entitled "Accredited Software Engineering Programs: Form and Content", it included three professors (Parnas of McMaster, Tim Lethbridge of the University of Ottawa and Mike Lutz of Rochester Institute of Technology) whose respective universities have undergraduate software engineering programs which either are or soon will be seeking accreditation, and Jim Waldo of Sun Microsystems. During the conference itself, there were six papers on software engineering education, plus a panel on SWEBOK [1] moderated by Peter Freeman, Dean of the College of Computing at Georgia Tech University (and which included Don Bagert, FASE Professional Issues Editor). An issue frequently brought up during the question and answer period of the session was the fact that many people still see the SWEBOK project as linked to the licensing and certification of software engineers, which was a contributing factor to ACM's Withdrawal from the Software Engineering Coordinating Committee last year (see "ACM Withdraws from SWEcc" in the July 2000 FASE). References [1] Bagert, Donald J.; Dupuis, Robert; Freeman, Peter; Saiedian, Hossein; Shaw, Mary and Thompson, J. Barrie. Software engineering body of knowledge (SWEBOK). Proceedings of the 23rd International Conference on Software Engineering, Toronto, Canada, 12-19 May 2001, pp. 693-696. ###################################################################### By: Don Bagert (Professional Issues Editor) New SE Professional Society Holds Workshop The new Software Engineering Society (SES) held its first major event, the Workshop on Global Transdisciplinary Education Research and Training, on 11-13 June 2001 in Pasadena, California, USA. The SES has a vision "of raising Software Engineering to new heights it deserves as the first true transdiscipline - the discipline in between disciplines." Its mission is "Serving Software Engineers throughout the world." The Software Engineering Society was founded by computing pioneers C.V. Ramamoorthy and Raymond T. Yeh. For more on the Software Engineering Society, see http://www.ssenet.org ###################################################################### From: Canadian Council of Professional Engineers via several sources Canadian Council of Professional Engineers and Microsoft Corp. Agree on use of "Engineer" title Ottawa, Ontario, May 11, 2001 - After discussions with Canada's engineering profession, Microsoft Corp. will advise Canadian holders of its MCSE certification not to call themselves engineers or use the full title Microsoft Certified System Engineers. Microsoft's decision should prevent Canadian holders of the MCSE certification from inadvertently breaking provincial and territorial laws, which protect the public by restricting the use of the titles "engineer" and "engineering" and the practice of engineering in Canada to licensed professional engineers. It should also ensure that the engineering profession's licensing bodies will not be required to take enforcement action against MCSE holders who mistakenly use the title engineer or otherwise hold themselves out as having been qualified to practice engineering. "We are very pleased by Microsoft's decision," said Marie Lemay, P.Eng., CEO of the Canadian Council of Professional Engineers (CCPE). "Microsoft has demonstrated corporate leadership by acting in the best interest of the MCSE community. Holders of the MCSE certification are not licensed or regulated by the engineering profession. If they mistakenly use the titles "engineer" and "engineering" the provincial or territorial engineering associations/order would have to take enforcement action against them. Its decision is good for the information technology industry, good for MCSE holders, and good for the engineering profession." The engineering profession, represented by CCPE and several provincial engineering regulatory associations, met with Microsoft in Seattle late last year to explain the legal issues surrounding the use of the title "engineer" in Canada, and to ask the corporation to stop referring to holders of the MCSE credential as engineers. Canadian MCSEs have received certification as Microsoft Certified Systems Engineers, which could lead them to mistakenly misuse the title "engineer." "We are very pleased to have reached an agreement with the engineering profession and to support it," said Anne Marie McSweeney, the acting Director of Microsoft Certification and Skills Assessment. "It opens the door for closer cooperation among all organizations in the information technology industry and the engineering profession in Canada. As the Microsoft credentials continue to evolve, it is our goal to ensure they maintain the highest level of relevance to the industry and represent leaders in cutting-edge technology." Microsoft is currently researching alternatives for the MCSE credential worldwide, which could result in a new name for the credential later this year. CCPE is the national organization of the provincial and territorial associations/ordre that govern the practice of engineering in Canada and license the country's 157,000 professional engineers. Established in 1936, CCPE serves the associations/ordre, which are its constituent and sole members, through the delivery of national programs which ensure the highest standards of engineering education, professional qualifications and ethical conduct. For More Information Contact: Terence Davis, Manager, Communications, CCPE 613 232-2474, ext. 238 ###################################################################### From: UT-Dallas via Scott Andresen of IEEE-CS UT-Dallas to Launch Software Engineering Degree Program New Bachelor's Degree to be One of Few Such Offerings in the Country RICHARDSON, Texas (June 7, 2001) - The University of Texas at Dallas (UTD), which several years ago became the first university in the United States to offer a bachelor's degree in telecommunications engineering, is preparing to join the ranks of a select group of universities that grant a B.S. degree in software engineering. Students in U.T. Dallas' Erik Jonsson School of Engineering and Computer Science will be able to enroll in classes under the new degree program beginning this fall. UTD, with one of the top-ranked engineering and computer science programs in the nation, already offers a master's degree in computer science with a major in software engineering. In addition, the university is reviewing a proposal to begin offering a Ph.D. degree in the same discipline. "This new degree program will both broaden the scope of UTD's engineering and computer science offerings and help meet the increasing need from industry for software engineering training," said Dr. Simeon C. Ntafos, professor of computer science, who this fall will become director of a new Software Engineering and Systems Division of the Computer Science Department. "UTD will become one of only a handful of universities in the U.S. to offer a degree in this rapidly-growing field." According to Ntafos, the software engineering degree should have substantial appeal to the North Texas region's "Telecom Corridor," home to as many as 900 high-technology companies. Many of those firms, located in close proximity to UTD, have close ties to the university through involvement in research and hiring its graduates. The new degree program will be similar to that of an undergraduate computer science degree, but will require that students enroll in five courses specific to software engineering - basic software engineering, requirements engineering, software architecture, testing and quality assurance and a "capstone" project. The project class, to be taken during a student's senior year, will involve student teams taking a substantial software system through all stages of development. UTD will seek ABET accreditation for the software engineering degree, Ntafos said. For additional information about UTD, please visit its web site at http://www.utdallas.edu. ###################################################################### By: Don Bagert (Professional Issues Editor) Parnas Writes Pro-Licensing Article for Canadian Engineering Magazine Professor David L. Parnas, one of the pioneers of software engineering and a licensed professional engineer in the province of Ontario, Canada, contributed the Viewpoint article "Why Software Developers Should be Licensed" for May/June 2001 issue (Volume 22, Number 3) of Engineering Dimensions magazine, on pages 36-39. (Engineering Dimensions is published by Professional Engineers Ontario.) Parnas writes: "Over the last few decades, software has been replacing mechanical, electrical and electronic components in traditional engineering products. It has also become a critical component in medical devices, chemical plants, buildings, and aircraft. Software is regularly used to design critical products, the effectiveness and safety of which can depend on the correctness of that software... "...Licensing and certification are needed to identify those who have the appropriate educational background. Licensing is essential for professionals who deal directly with the public or who are responsible for critical products. Certification will be useful to those who will be a part of a team and report to more senior professionals who are able to evaluate their work." ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Heidi Ellis TOOLS USA 2001 Workshop on Education and Training (WET) Sunday, July 29th, 2001 FIRST ANNOUNCEMENT AND CALL FOR PARTICIPATION This year, the Workshop on Education and Training will focus on the relationship between industry and academia, concentrating on two loosely-related themes: -- in educating and training the next generation of software engineers, what should academia do and what should industry do? -- how can industry and academia further exploit the Internet for education and training? You are cordially invited to submit a one to two page position paper addressing either or both of these themes. Your paper should cover: your interest in the topics, any relevant experience you can bring to the workshop, a brief autobiography, and contact information. Position papers should be submitted by June 15th, 2001 (flexible) by e-mail in plain text format to the workshop organiser, Heidi Ellis (heidic@rh.edu). The Workshop will be informal in style, as in previous years. Emphasis will be placed on exchanging hard-won experience and forming useful contacts for the future. We hope to be able to welcome you to the Workshop in beautiful Santa Barbara! Further details: Heidi Ellis, Associate Professor Dept. of Computer and Information Sciences Rensselaer at Hartford 275 Windsor St. Hartford, CT 06120 Richard Mitchell, InferData Corporation ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Position Openings ###################################################################### From: Fran Devore Illinois Wesleyan University Bloomington, Illinois 61701 Department of Mathematics and Computer Science The Department of Mathematics and Computer Science at Illinois Wesleyan University seeks an individual to teach first year courses in computer science and/or mathematics in either a full-time or part-time position. The appointment will be for the fall term and will begin in August 2001. Reappointment for the spring term 2002 should be possible. Candidates should have a graduate degree in either Computer Science, Mathematics, or a related area. Illinois Wesleyan University is a highly selective undergraduate university of approximately 2,000 students located in Bloomington, Illinois, a community of about 120,000. The Department of Mathematics and Computer Science is located in the Center for Natural Science Learning and Research, a $25,000,000 facility opened in 1995. Candidates for the position should submit a letter of application, a resume, and have three letters of recommendation sent separately to: Judy Huff, Natural Science, Illinois Wesleyan University, P.O. Box 2900, Bloomington, IL 61702-2900 [jhuff@titan.iwu.edu, (309) 556-3060] Applications will receive immediate attention. The University invites retired faculty and ABD's to apply. Women and minorities are encouraged to apply. Illinois Wesleyan is an Equal Opportunity Employer. For further information see our jobs web page at: http://www.iwu.edu/~iwujobs ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Contact and General Information about FASE FASE is published on the 15th of each month by the FASE staff. Article and Faculty Ad Submission Guidelines Send newsletter articles to one of the editors, preferably by category: Articles pertinent to academic education to Tom Hilburn ; corporate and government training to David Carter ; professional issues, faculty ads, and all other categories, to Don Bagert . If the article is for a FASE topic where there is a guest editor, the submission should instead be to that person, according to the schedule provided. Items must be submitted by the 8th of the month in order to be considered for inclusion in that month's issue. Also, please see the submission guidelines immediately below. FASE submission format guidelines: All submissions must be in ASCII format, and contain no more than 70 characters per line (71 including the new line character). This 70-character/line format must be viewable in a text editor such as Microsoft Notepad WITHOUT using a "word wrap" facility. All characters (outside of the newline) should in the ASCII code range from 32 to 126 (i.e. "printable" in DOS text mode). _____ Subscribe/Unsubscribe Information (as of February 15, 2000) Everyone that is receiving this by email is on the FASE mailing list. If you wish to leave this list, send a message to and, in the text of your message (not the subject line), write: unsubscribe fase To rejoin (or have someone else join) the FASE mailing list, write to and, in the text of your message (not the subject line), write: subscribe fase For instance, if your name is Jane Smith, write: subscribe fase Jane Smith But what if you have something that you want to share with everyone else, before the next issue? For more real-time discussion, there is the FASE-TALK discussion list. It is our hope that it will be to FASE readers what the SIGCSE.members listserv is to that group. (For those of you that don't know, SIGCSE is the ACM Special Interest Group on Computer Science Education.) To subscribe to the FASE-TALK list, write to and, in the text of your message (not the subject line), write: subscribe fase-talk For instance, if your name is Jane Smith, write: subscribe fase-talk Jane Smith Please try to limit FASE-TALK to discussion items related to software engineering education, training and professional issues; CFPs and other such items can still be submitted to the editor for inclusion into FASE. Anyone that belongs to the FASE-TALK mailing list can post to it. As always, there is no cost for subscribing to either FASE or FASE-TALK! (Subscriptions can also be maintained through the Web via http://lyris.acs.ttu.edu. From there, click on "TTU Faculty Mailing Lists", and then either "fase" or "fase-talk", depending on which list you desire.) _____ Back issues (dating from the very first issue) can be found on the web (with each Table of Contents) at in chronological order, or in reverse order. _____ The FASE Staff: Tom Hilburn -- Academic Editor Embry-Riddle Aeronautical University Department of Computing and Mathematics Daytona Beach FL 32114 USA Phone: 904-226-6889 Fax: 904-226-6678 Email: hilburn@db.erau.edu URL: http://faculty.erau.edu/hilburn/ David Carter -- Corporate/Government Editor 6212 Mil Mar Blvd Alexandria LA 71302 USA Phone: 318-767-2339 Email: dacarter@bayou.com Don Bagert, P.E. -- Professional Issues/Misc Editor and Web/Listmaster Department of Computer Science 8th and Boston Texas Tech University Lubbock TX 79409-3104 USA Phone: 806-742-1189 Fax: 806-742-3519 Email: Don.Bagert@ttu.edu URL: http://www.cs.ttu.edu/faculty/bagert.html Laurie Werth -- Advisory Committee Taylor Hall 2.124 University of Texas at Austin Austin TX 78712 USA Phone: 512-471-9535 Fax: 512-471-8885 Email: lwerth@cs.utexas.edu Nancy Mead -- Advisory Committee Software Engineering Institute 5000 Forbes Ave. Pittsburgh, PA 15213 USA Phone: 412-268-5756 Fax: 412-268-5758 Email: nrm@sei.cmu.edu