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 intention 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

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

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 name if necessary). It must be possible to print out all the entries in the address book in "mailing label" format.

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.

The initial requirements call for the program to work with a single address book. A later extension might allow for multiple address books to be open, each with its own window which can be closed separately, with closing the last open window resulting in terminating the program. In this case, New and Open will result in creating a new window, without affecting the current window.

The program will keep track of whether any changes have been made to an address book since it was last saved, and will 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 to quit the program.

The program will support importing and exporting a set of addresses. The import/export format will be 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.

Quality Requirements:

A useful system will need to meet some quality requirements:.

Likely Changes

  1. Add additional fields to the entries: for example, fields for someone's e-mail, mobile phone, and business phone.
  2. Ability to edit the name fields (or other) at any time while keeping the associated data.
  3. Ability to sort on other fields.
  4. As the number of entries gets larger, we will want to be able to search the address book.

Subsets and Extensions

  1. Simpler version with only name and phone number
  2. Allow user-defined fields
  3. Support multiple address books with different fields

Developmental Objectives

Speed of development, software quality, and flexibility of the design are paramount.

L0: Minimum Useful Subset

All teams should complete a minimum useful subset as follows:

L1: Version 1

L2: Version 1.1

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.

Project 2: Choose a Project

The second project has two objectives:

For Project 2, teams will have a choice of projects. Teams may either implement one of the projects suggested here 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. As usual, the draft ConOps should characterize the expected system capabilities from different users perspectives. 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. For teams choosing one of the sponsored projects, the team is encouraged to meet with the sponsor before finalizing the proposal.

1. Deschutes Interactive Display (Customer: Prof. Steve Fickas)

The CIS Department is planning to install an interactive display in the entryway of Deschutes Hall. Prof. Fickas is looking for applications to run on the display that would showcase our student's work and abilities. The basic idea will be to create an application that visitors can interact with using the display and a mobile device (cell phone, tablet). A range of application are possible including games, department information, etc. Prof. Fickas will present this project in class on Wed., Oct. 23.

2. Reality TV Data: a Web-based Visualization Tool (Customer: Chelsea Bullock)

Chelsea is a graduate student in English seeking a tool for visualizing data about the history of reality television. The visual representation of growth of reality television, particularly from 2008 onward, will useful for analyzing trends in this medium. The objective will be to create an open source, user-friendly, and adaptable application suitable for non-technical users. The tool will likely input textual data on individual shows: years on air, network/channel, sub-genre category, and title. Users would then be provided an interface allowing them to visualize, organize, maniputlate, and search the data using different criteria. E.g. limiting results to only display shows that premiered in 2010 and are still on air on Bravo and E! I imagine data sets that move and aggregate data based on users’ desired filters. Filtering data is a crucial part of the tool. An unattractive but functional example can be seen at: http://databench.zepheira.com/demos/nobelists/nobelists.html.

This is a potentially interesting project for 422/522 students in that: 1. it will include interaction with a live customer and 2. the proposed functionality would be broadly applicable to visualizing many kinds of data (not just reality TV), 3. It provides a good opportunity to explore UI design.

3. Project Risk Tracking Dashboard (Customer: Stuart Faulk)

The objective of CIS 422 projects is to develop an open-source quality application in a way that maximizes the scores on the course grading criteria. It would be useful to 422 instructors and students to have an application that tracks project progress and provides feedback on the extent to which the project is on track for a "A" grade. The application would use the assembla API to retrieve data about the status of deliverables (e.g., Project Plan, Requirements, etc.). It might then compare this to the project schedule or other data to create a metric of project progress. This could be turned into one or more graphics showing the progress of the project against grading criteria (and/or the project plan).

An open-source version of the tool could be usable by a wide range of teams using Assembla as a development workspace.