F.Y. Chan, R. McFadyen, C.R. Peterkin, and S. Ramanna

In this paper we discuss our capstone course, 91.4901/6 Senior Systems Development Project, a required course in our Four-Year Major in Business Computing. The course is designed to apply learned software engineering (SE) concepts to a practical project. This course is unique because students are organized into teams, and each team is assigned a real-world development project to be completed in two academic terms. Team sizes have ranged from four to nine. Our sponsors have come from private enterprise representing various sectors such as transportation and health-care, non-profit organizations, and government (provincial and federal governments). The sponsors' environments represent a wide diversity of technologies. Our capstone course has been successful as demonstrated both by the many systems that have gone into production and by the several repeat sponsors we have had.

The three principal objectives of this course are to:

Over the period of two terms, each team goes through a software development life cycle producing, at the end, a working system meeting the requirements of the sponsor. Since team members are students and not paid employees, our department carefully assesses the scope of proposed projects to ensure that the workload of each student is commensurate with the workload of an academic course. In section 2, we discuss the course preparation that must be made for each offering. In section 3, we discuss the delivery of the course. Section 4 describes several challenges we have faced and lessons we have learned. In section 5, we offer some concluding remarks.

Before the course starts in the first term, there are a number of issues that must be taken care of in order to ensure the success of the course. Before we begin discussing these issues, we will briefly review some roles played by faculty involved in the course. Each team has an Information Systems Director (a faculty member) to provide guidance, assistance, and supervision. One of the IS Directors takes on the additional role of Course Coordinator,  responsible for the overall coordination of teams, projects, and facilities. Assisting the Coordinator is the department's System Administrator, also a faculty member, who provides technical advice and support to the teams.

Each year, the Course Coordinator conducts an information session in March for prospective students who are planning to take the course in the first term the following September. During this session, every student is given a questionnaire to fill out and return to the Course Coordinator in the last week of April (end of the second term). Submission of a completed questionnaire is mandatory, since the information contained in the questionnaire is crucial input that a Course Coordinator needs in forming a balanced team. The Course Coordinator is also responsible for soliciting projects. All IS Directors meet over the months of July and August to:

A remarkable feature of the course is the very high level of involvement in this course by all faculty members. An illustration of this is the participation of all IS Directors and all department members in the major milestone status reviews that take place at the end of General Design.

We will now provide additional details on two important aspects of preparation for the course.

2.1 Selection of Sponsors

Our prime objectives in selecting sponsors are to ensure that the proposed project fits well into the academic objectives of the course, that the scope is appropriate (or can be adjusted as needed), and that the sponsor recognizes that this is primarily a learning experience and is eager to participate in it. We require that all prospective sponsors submit a request form, on which they describe the nature of the project they would like a team to undertake. If the project appears to meet these criteria, then a site visit and detailed assessment take place in the summer, as outlined above.

Potential sponsors may learn about the Project course in several ways. Word of mouth is common. Project sponsors in previous years have often mentioned the course to others. This has worked particularly well inside the university. Also, faculty members in the department are ever conscious of the need for good project sponsors. Therefore, as we deal with contacts both inside the university and in industry, we are on the lookout for possible projects and raise that possibility when appropriate. A third source is the students themselves. Students in the department are well aware of the Project course and have proposed several project sponsors, often arising from part-time employment or a family business.

Some of our projects come from repeat sponsors. These typically arise in one of two ways. The scope constraints arising from the academic environment often result in cutting out relatively major components of the originally-proposed system. This will sometimes be done as part of our detailed assessment before the course starts, but scope issues often arise again at the status reviews, particularly at the end of the Systems Study and Detailed Design phases. The components that are cut out sometimes give rise to a second phase, to be done the following year by a new team. Secondly, satisfied project sponsors have often requested another team in a subsequent year to work on a different system for them, typically one sitting in their application backlog.

2.2 Team Formation

When forming teams, we strive for balance in several dimensions, including overall academic performance, specific skills from earlier courses or personal experience, sex, ethnicity, communications skills, maturity, and leadership abilities. As mentioned above, team formation is the responsibility of the Project Coordinator. We have found that a team size of five or six students has worked best. Earlier in the course's history, we allowed the students to form teams on their own, with help from the Coordinator if needed. This self-selection process frequently resulted in a set of teams with very different practical abilities and general academic competence. The department feels a strong responsibility to both the students and the sponsors to put everyone on the best possible footing for success. Ensuring that the teams have an appropriate mix of characteristics reduces risk for both students and sponsors. We do still allow students to express preferences for team members if they have any, but it is made clear from the outset that these will be accommodated only if it is possible to do so without skewing any of the dimensions we view to be essential.

Forming the teams is a painstaking task, given the number of constraints. Various Coordinators have come at the process in different ways. We will describe one such approach. From the pool of available information on each student, for example, the questionnaires, student transcripts, and general knowledge of the students, choose the Project Leader for each team first. The Project Leader will typically have a good academic record, good communications skills, maturity, organizational skills, and a willingness to help out others, among other characteristics. In addition to the Project Leader's primary responsibility for project management, this person typically assists the Lead Analyst. Then choose the Technical Leader. This person will ideally also have a good academic record and communication skills, but this person's primary focus will be on the technical side, as opposed to the analysis side. From there, choose the Lead Analyst and Lead Programmer. Of course, all of these selections should be done with regard to the general balancing criteria mentioned earlier. The team now has a core of two people on the analysis side and two on the technical side. From there, round the team out with the Quality Assurance Specialist (if different from those members already chosen) and additional analysts and programmers. How many further team members are added will depend of course on the team sizes for that year. Finally, evaluate the teams for balance in each dimension and adjust as necessary.

Though we build the teams with the various roles in mind, we do not impose all of these roles on the team when the project begins. One of the first duties of the assembled team in September is to decide internally within the team what roles they wish to perform. This process works well as an ice-breaker and team-building exercise. Team members are usually able to sort out their roles without difficulty, occasionally asking the IS Director for guidance. The Project Leader role is a special case. If a team were to recommend a different Project Leader from the one assigned by the Coordinator, we would need to examine the request very carefully before agreeing.

The course comprises two components: theory and project. The theory component comprises formal classes in the first term on project management, followed by an examination. All IS Directors participate in designing common case-study questions for the examination. The project component begins in the first term in parallel with the theory component. Each team member is required to play at least one of the following roles: Project Leader, Technical Leader, Systems Analyst/Designer (lead), Programmer (lead), and Quality Control Specialist (lead). The Course Coordinator and System Administrator conduct regular monthly meetings with the Project Leaders to help with project logistics. The Course Coordinator provides regular meeting facilities for all teams for project meetings with IS Directors and sponsors. The System Administrator provides software, hardware, and installation assistance for all teams. The project teams follow a standard life cycle; some typical deadlines and milestones are illustrated below.

3.1 Milestone Reviews

Included in the table above are two formal milestone status reviews and a final presentation that will be described shortly. In keeping with current software engineering and IS practices, our teams are required to follow a product standard [6] and a process standard [1]. These structuring mechanisms serve as a guide for the conduct of the course. The culmination of the course is celebrated as a Project Day that includes a presentation and system demonstration by each team to a wide-ranging audience.

We have several objectives in requiring formal reviews. We want of course to ensure that the project stays on track in all respects (requirements, external and internal architecture, scope, quality, etc.), especially in view of the academically-imposed constraints on time. Secondly, we want our students to come to see status reviews as a natural and necessary part of systems development. Finally, we want to give the students the experience of planning a major review; designing, developing, and delivering the material; and handling sometimes very probing questions and concerns raised during the meeting. The two formal milestone status reviews occur at the end of the Systems Study and Detailed Design phases. Prior to each review, the team prepares and distributes supporting documentation for discussion in the meeting. The documentation is essentially a collection of all the deliverables from that phase, assembled into a formal report conforming to the guidelines in the Standards Handbook [6]. We emphasize the importance of good report-writing, and the IS Director reviews his/her team's reports before they are distributed.

Other, less-formal reviews are held throughout the rest of the life cycle as needed, with participants such as the team itself, the IS Director and the team, or the team and the end-users. The nature of the project itself may affect whether a particular review takes place or not. For example, we have undertaken a few projects in which the true requirements did not come clearly into focus for several weeks, because of, for example, multiple user units, user indecision, or legitimate competing views about priority. In such cases, we have called a review meeting with all the appropriate participants at the end of the requirements-gathering sub-phase to ensure that everyone was in agreement.

Systems Study Review

The first of the required formal status reviews is the Systems Study Review. It covers the work done up to the end of the General Design phase in our methodology. Participants include the team, all IS Directors, the rest of the Business Computing faculty members, the project sponsor, selected end-users, and other parties as appropriate, for example, end-user technical support staff. In preparation for the review, the team produces a Systems Study Report that includes such deliverables as an analysis of the existing system; a statement of requirements; a cost/benefit study on proposed solution alternatives; preliminary screen and report designs; high-level data and process models; plans for testing, training, data conversion, and implementation; and a revised project plan. In the two to two-and-a-half hour review meeting, the team presents these deliverables for discussion. The team also raises issues outside the application itself, such as scope, privacy and security, and network considerations. Finally, the revised project plan is presented, including an analysis of estimates and actuals to date. The collective feedback from the status review usually results in the need for some rework by the team. The end result of this wide-ranging review is that all interested parties have had the opportunity to provide input, and now everyone is in agreement on major aspects of the development effort, such as requirements, scope, platform, development tools, upcoming milestone dates, and the high-level data model, process model, and user interface.

The Detailed Design Review

This review is similar to the Systems Study Review in many respects. The team prepares the Detailed Design Report, containing the results of its work in this phase. This report, along with an expanded prototype, provides the foundation for the review meeting. The team also walks through its current prototype of the user interface, which has been fleshed out considerably since the previous review and may now exhibit some minimal functionality. The participants for this review may change somewhat from the earlier one. Though all IS Directors are welcome to attend any Detailed Design Review, it is common for only the IS Director for that team to be present. On the sponsor side, additional, hands-on staff may attend. If the person who originally sponsored the project is at a high level in the organization, that person may decide not to attend this review, leaving the details to staff who will be more directly affected by the new system.

Project Completion Seminar

About a week before the end of the academic term, each team conducts a final seminar on its work and experience over the past seven months. On the same day, our senior project lab is converted into a demonstration room. The teams are available to demonstrate and discuss their systems with visitors. Each team is asked to prepare in advance an illustrative, ten-minute walkthrough of its system, so that all visitors, irrespective of their levels of computer literacy, will benefit from stopping by the teams' workstations.

The content of the seminar is supported by a Project Completion Report, whose contents include an overview of the system just built; the completed project plan, with an analysis of estimates and actuals and project management techniques used; an evaluation of the hardware environment and development tools used; a list of known future enhancements that could be usefully made to the just-delivered system; and a set of recommendations by the team to both future project students and the Business Computing department. The teams have an opportunity to share their experiences, comment on what went well and not so well, how they would do things differently in a future project, and what they feel they have learned from ushering a system through the entire life cycle. This seminar is open to a wider audience than the previous ones. In addition to inviting the sponsors and all faculty members in the department, we cancel classes for the day and invite all Business Computing students to attend. We also invite members of the IS community, some of whom attend with recruitment in mind. Parents, relatives, and friends are welcome also. Several graduates of Business Computing, now themselves in industry, have come back to observe the current teams and renew acquaintances in the department. For the IS Directors in particular, this is a very satisfying day, as we recall the very real-life events that took place during the course and see the project students make highly professional, well-organized, insightful presentations on their systems and experiences in the capstone course in their degrees.

As is the case with many computing programs, our department faces some unique challenges in running such a resource-intensive course. Each project and team is unique; this requires us to be diligent when assessing project complexity and student workloads. Firstly, team members are students and not seasoned professionals; the students have varying degrees of technical, language, and interpersonal skills. Secondly, the software engineering discipline and technology is always changing. Lastly, we cannot assume the responsibility of providing maintenance/enhancement of the developed product, and so our selection of potential projects is restricted to those sponsors that have competency in product maintenance or are able to outsource post-implementation support. Some systems have been great success stories, having become operational icons on user desktops. However, some systems are never used. There are several contributing factors:

To help our students better manage and appreciate the changing nature of requirements, we encourage them to incorporate new approaches and tools into their development efforts. Among these are the following:

Requirements Matrix: The concept of the matrix illustrates that both effort and time are necessary to understand and clarify the requirements. It can serve both as a planning and tracking tool. In addition, it captures both the original high-level ideas and their evolution/changes, thus reflecting the changing nature of requirements gathering.

Use Case approach: Most recently, our students have begun to incorporate more advanced techniques, such as Use Cases, into their work. A Use Case is a description of an interaction between a user and a computer system [3]. Use Cases have been incorporated in the industry standard Unified Modeling Language (UML).

Software Architecture: Given the diverse set of applications and design methodologies, we have begun to study and assess software architectures as a part of the general approach to system design. The main purpose of the architecture is to enable high-level system decisions that will provide consistency and reduce risks in the design and development of the software.

The project course offers students a unique hands-on experience in applying software engineering and IS development concepts while still in an academic environment. This is in contrast to a co-op option that is offered in many programs. In our program, the students experience the entire systems development life cycle in a team environment, and receive their guidance and direction from faculty members. A very valuable challenge for our students is that a development project requires them to observe and apply concepts that they have been exposed to in their courses over the previous three academic years. The very nature of such a course means that demands (sometimes unreasonable!) are made on faculty as well. The inception, stewardship, standardization, and on-going improvement of the course have drawn upon many different professional skills and personalities. The course has benefited from both steadfast steering and calculated risk-taking. Even though the course is very demanding for both students and faculty alike, the experience obtained by the teams and our continued success at finding worthy project sponsors keep the course at the forefront of our program. A case in point is "The Mutual Fund Challenge" project [7] that began as a departmental initiative to provide web-based support for an Introduction to Business course in which students are taught concepts of investing. After its creation, a department member sought sponsorship by the TD Bank, which is now funding a part-time student system administrator for corrective and adaptive maintenance and assistance for end-users. This simulation is currently a part of several high-school curricula across Manitoba, and a nation-wide release is being planned in the immediate future.

1. F. Chan, C.R. Peterkin, and S. Ramanna, Senior Systems Development Course Project Handbook, Business Computing Department, University of Winnipeg, 2000.
2. Jacobson, Ivar, Object-Oriented Software Engineering. Addison Wesley, 1992.
3. Peters, J.F. and W. Pedrycz, Software Engineering: An Engineering Approach. John Wiley & Sons, Inc., 2000.
4. Pressman, Roger S, Software Engineering: A Practioner’s Approach. McGraw Hill, Inc., 2000.
5. Werth, L.H., Integrating Software Engineering into Introductory Computer Science Courses, Computer Science Education 8 (1) (March 1998).
6. F. Chan, C.R. Peterkin, and S. Ramanna, Senior Systems Development Course Standards Handbook, Business Computing Department, University of Winnipeg, 2000.
7. http://www.mutualfundchallenge.com