Skip to main content.

Overall Project Organization

We use the first 9 weeks of the term for design and construction of projects. Week 10 is reserved for final presentations. A more complete schedule is available.

Every team will work on two software projects. The first project is intentionally simple with respect to the code that must be developed; the goal is to allow team members to learn to work together, develop an understanding of the software development process, and get feedback on their work products. Feedback will be provided by peer-review as well as by the instructor. Students should complete Project 1 with a good understanding of the issues of collaborative software development and how these issues can be addressed through a disciplined software process.

Project 2 will be a more significant development effort that should produce a usable software application. Students may choose from among projects suggested by the instructor or may submit a proposal for a project of their own.

Project 1: A Simple Address Book

Objectives

For most teams, the hard part of this project will not be the coding, but organizing the team to work effectively together, and being clear on exactly what the team is building, in particular:

  1. Requirements: getting clear on precisely what the software should do and communicating this to all team members.
  2. Work Assignments: being precise about the tasks assigned to each person; exactly what is to be produced and when it is due.
  3. Iteration: building the code up as a sequence of meaningful subsets of the eventual functionality in a way that can easily be extended.
  4. Design: communicating the major software design decisions and their rationale.

The software to be designed is a program that can be used to maintain a simple address book. At a minimum, an address book holds a collection of entries, each recording a person's first and last names, address, city, state, zip, phone number and e-mail address.

Initial Requirements

It must be possible to add a new person to an address book, to edit existing information about a person, and to delete a person. It must be possible to sort the entries in the address book alphabetically by last name, or by ZIP code (with ties broken by first name if necessary).

It must be possible to create a new address book, to open an existing address book, to close an address book, and to save an address book to a file. File operations should be performed using standard New, Open, Close, Save and Save As ... File menu options. The program's File menu will also have a Quit option to allow closing all open address books and terminating the program.

Basic requirements call for the program to work with a single address book. A better implementation should allow for multiple address books to be open, each with its own window that can be closed separately. In this case, New and Open will result in creating a new window, without affecting the current window.

The program should keep track of whether any changes have been made to an address book since it was last saved, and offer the user the opportunity to save changes when an address book is closed either explicitly or as a result of choosing to create/open another, or quitting the program; i.e., it will not lose unsaved data without warning.

A more advanced implementation of the address book should support importing and exporting a set of addresses to other address books (e.g., to share addresses with another user). Import and export will be done using a standard, customer supplied, format (a TAB separated list of entry fields).

It is anticipated that the address book application will be routinely updated to add features, improve capabilities, or improve quality. It must be possible to extend and update the address book design as requirements change.

Quality Requirements:

A useful system must meet at least the following quality requirements:.

More Advanced Features (Likely Changes)

Once the basic functionality is implemented it is expected that the team will add one or more advanced features. The system should be designed so that such changes are easy to make. An advanced design will implement one or more of these features.

  1. As the number of entries gets larger, we will want to be able to search the address book.
  2. Ability to keep customized address books with different types of entries in each.
  3. Support for user-defined fields.
  4. Include links to social media like Facebook

Developmental Objectives

The first objective should be to build something the customer (played by the instructor) actually wants. In addition, speed of development and software quality are critical.

Suggested Subsets

Teams should employ an incremental development strategy that builds first an application with a small subset of the expected features. Subsequent increments should add additional features. Teams may decide which features to implement first but the following is a reasonable approach.

L0: Minimum Useful Subset

All teams should complete a minimum useful subset as follows:

L1: Basic Address Book

L2: Advanced Address Book

Constraints

It is required that at least two team members contribute to each of the significant artifacts. In particular, that two or more must contribute significantly to the code, work on the design, create the documentation, provide reviews, and test results. It should be clear from the schedule and developer log which team members contributed to each artifact.

Project 2: Choose a Project

The second project has two objectives:

Teams will have a choice of projects. Teams may either implement one of the suggested projects or propose a project of their own. In either case, the team must submit a project proposal to the instructor. The proposal should be in the form of a draft ConOps document. Begin with a brief description, one page or less, characterizing the anticipated system capabilities from the user's perspective. In addition, the proposal should make the case for why the project will be an effective vehicle for demonstrating the team's understanding of Software Engineering concepts covered in class. A good project idea will include:

If you are considering several ideas, feel free to send me an e-mail if you would like my feedback.

A few project ideas:

CIS Grad Student Web Portal (customer: Prof. Michel Kinsy)

The CIS department envisions a comprehensive CIS grad student portal that provides everything the student needs to know or keep track of during their studies. The goal of this project is just to start this development so others can continue building on it in the future. Requirements will be worked out with the project customer (Prof. Michel Kinsy). This will include an initial structure for a web site supporting a subset of functionality required by CIS grad students to track their progress. For example:

Duck Hat

Not sure you buy in to the value of Top Hat in CIS 422? Think you can do better? This project would begin to implement an open-source replacement for Top Hat. While it is likely not possible to implement all of the features of Top Hat, it should be possible to provide basic facilities for asking and responding to questions in lecture. Ideally, the design would support easy extention to add different kinds of questions and support adding more suphisticated features. This project is large enough that it would support development by more than one team. For example, one team implementing the instructor interface and another the student (client) interface.

Team Meeting Planner:

This is a variation of the "better meeting planner" used by Prof. Michal Young in 399. Currently, it is difficult to identify open times that the CIS 422 instructor can meet with each team. Typically, this requires that the team members first identify when they can meet as a group, then try to find an open time to meetin with the instructor. A better Team Meeting Planner would consolidate team member schedules with open slots in the instructor's schedule to show all the times that would work for a meeting. Even better, the instructor's planner would show the times available for all of the different teams so the meetings could be scheduled efficiently (e.g., sequentially if possible). A preferred implementation would synch with Google Calendar to show meeting events.