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 entirely on the primary skills taught in the course.

• Student will be asked to develop requirements and architecture for things far too complex for them to possibly build in a one semester course. They will then conduct a formal design review. 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. The obvious danger of such an approach is that it would allow students to (unknowingly) develop bad requirements and designs, without (since they did not actually have to make the software work) real validation or feedback on the prgamatic quality of their efforts.

  The design review, in addition to teaching review skills, is intended to provide them with feedback on the quality of their requirements and architecture.

• In a second set of projects, students will develop specifications, a design and a test plan for a much simpler component, and to again submit this to design another design review. A more detailed design can be subjected to much more detailed scrutiny.

A secondary goal in these projects is to develop organizational, planning, time management, and post-mortem review skills. This is accomplished by not breaking large projects 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.

Project 1 - New Product Definition

This is a three-part team project in which students will have the opportunity to do preliminary analysis and design for a fairly large software product.

They will organize themselves into 3-5 person teams, and come up with a concept for an interesting new product. Then, in three sub-projects they will:

1. develop and validate requirements for a new product
2. develop an architecture for that product
3. conduct a design review of that architecture, and revise their architecture based on the input received

Before each of these sub-projects, they will prepare a schedule and plan of work. After each sub-project they will prepare a post-mortem of both their own work, and of the project as a pedagogical exercise.

Project 2 - Project 2 - Detailed Design Skills

The product designed in Project 1 is large enough to have interesting requirements and architecture, which means it is far too large to be implemented by four people in a few weeks. Therefore, we will shift to a simpler product in order to practice lower level specification, design, and testing skills.

Project 2 covers a broader range of activities, taking the students deeper into a smaller problem: the planning, specification, design and review of a module to plug in to a non-trivial framework. This project is broken down into the following phases:

1. Propose and plan the development of of a new GKrellM plug-in.
2. Research GKrellM plug-ins and write detailed specifications for that module.
3. Prepare a detailed design for that module.
4. Prepare a complete test plan for that module.
5. Conduct a design review for that design.
6. (optionally, for extra credit) code, build and test the module as specified.

   This part is optional (a) because of how busy the semester already is with the other projects and (b) because, given the degree of planning and specification that goes into the preceding steps, the actual implementation will be likely prove to be a fairly dull exercise.

In Project 1, I will have divided the work into three sub-tasks, and dictated a schedule for each sub-task. For project 2, they have almost as much work to do, less time to do it in, and they will have to propose (and manage to) their own schedules. There will be specific work-products to be submitted for each of the sub-projects, but the students will determine for themselves when they want to complete them. This will be a serious exercise of work planning and time management skills. As in project 1, they will continue to conduct a post-mortem and submit that report along with each of the sub-projects.

Conclusion