Computer Science 121 - Introduction to and Overview of Projects

Introduction and Background

It is traditional, in Software Engineering courses, to have students build a large project. This is intended to give students the opportunity to apply many of the skills covered in the reading and lectures. And I must concede that building software is the most obvious form for projects in a Software Engineering class to take.

In looking at what students have actually done in these projects, I have found a few major concerns:

• Students are expected to develop coding and debugging skills in the lower division programming series. The academic material in a Software Engineering course deals with project models, work products, requirements, analysis, design, (representation, characteristics of good designs, processes for evolving them), review, testing, and an introduction to projects, process, and organization.

  In a typical Software Engineering project, students spend (at best) 25% of their time on these activities, and 75% of their time coding and debugging. This is realistic (in that it mirrors real software development) but it doesn't provide much opportunity for the students to apply the taught techniques and develop the associated skills.

• The success of a small software project probably has more to do with the motivation, skill, and experience of the development team than with the methodology they employ. Software Engineering disciplines evolved to manage the risks and complexities of large projects.

  The typical Software Engineering project involves a one digit number of staff-months of work ... the size of a single task in many large software projects. While these projects are highly educational, and a necessary step in the development of discipline and skills, they seem (to me) too small to demand significant exercise of "Software Engineering" (as opposed to programming) skills.

• Projects (whether research or commercial) seldom fail because the developers lacked sufficient familiarity with languages or other programming tools. Projects fail because of:
  • poor requirements
  • lack of a concrete plan
  • having a bad plan, and not realizing it
  • failure to recognize and obtain required resources
  • failure to recognize and respond to problems
  • poor time and resource management
  If this course is to make a difference, it must address these problems.

My goal, in defining projects for this course, has been to create a series of projects that will focus primarily on the primary skills taught in the course.

• In small teams, students will be asked to develop requirements and architecture something larger more complex than can usually be built a team in a one semester course. The advantage of this approach is that they will gain the opportunity to exercise important skills that would be poorly (if at all) exercised by smaller projects.
• In this second phase, the students will select one of the proposals developed in project 1 and:
  • develop and oversee a project plan
  • develop, elaborate, review and maintain an architecture.
  • deverop, review, and maintain specificiations.
  • develop and review designs for all implied components
  • develop and implement component test plans
  • develop and implement system test plans
  • put the product in customer hands, and get feedback on it
  Having a much larger number of students to divide the work among makes the programing for a much larger project tractable.

Another goal of these projects is to develop organizational, planning, time management, and post-mortem review skills. This is accomplished by not breaking the second project into small pieces, but rather, requiring the students to do this. The students are not merely responsible for producing the required work products, but plans for their production. The project grades are based, in part, on the quality of the plans, the dilligence that was paid to them, and the insights gained in retrospect. It is further hoped that the post-mortem reviews will help consolidate learning of both process and technical lessons.

Thus the assigned projects should be seen, both in terms of the primary technical skills they exercise, and successively more demanding sets of project management responsibilities. I assert that it is these skills (and not additional programming ability) that are the primary focus of this course.

Conclusion