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 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 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 quitting the program; i.e., it will not lose unsaved data without warning.

The program must 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 will need to meet the following quality requirements:.

• Performance: the software should respond to user requests at a speed equal to or better than competing applications, in any event not to exceed 500ms.
• Reliability: the system should enter and retrieve or exchange properly formatted address book data without loss or error.
• Standards: the address book software should ensure that data entered is consistent with U.S. postal address standards.
• Consistency: it should be possible to edit the name (or other fields) at any time while keeping the associated data.
• Ease of change: it should be possible to make likely changes to the system without extensive re-design. Simple changes should require changes to only a single system component (module).

Likely Changes

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. Ability to invoke email, Facebook, or other linked applications from address book entries.
4. Ability to merge address books.
5. Support user-defined fields.

Developmental Objectives

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

• It must be possible to divide the software into a set of distinct components that can be coded and tested concurrently.
• It must be possible to scale the delivered product to meet schedule.
• A bug-free application with reduced capability that is delivered to the market on time is worth far more than a buggy or late application with lots of features.
• Likewise, a design that allows for features to be added easily is superior to one that satisfies initial requirements but is difficult to extend.

L0: Minimum Useful Subset

All teams should complete a minimum useful subset as follows:

• Add addresses
• Retrieve/view addresses
• Change address information and save

L1: Version 1

• Simple address book as described in the initial requirements including
• Store standard postal address and one phone number
• Sort addresses by name or zip
• Edit, save, and recall addresses
• Import/export standard-format (customer-defined) files of addresses
• GUI for entering accessing address book operations

L2: Version 1.1

• Print an address in mailing-label format
• Add additional fields to the entries: for example, fields for multiple email addresses, mobile phone number, business phone, birthday, etc.
• Support for two or more of the likely changes.

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:

• Demonstrate your grasp of Software Engineering principles and concepts
• Develop an open-source quality application that can be demonstrated or downloaded

For Project 2, 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, then expand as needed. As usual, the draft ConOps should characterize the expected system capabilities from different user's 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 covered in class. A good project idea will include:

• An interesting idea for an application.
• Enough complexity that the project needs to be effectively modularized and developed concurrently among team members.
• Enough different capabilities that the project can be sensibly divided into increments. Each increment should represent a useful subset of the application capabilities so the team will have something to turn in even if every feature cannot be completed.
• Small enough scope that a complete set of development artifacts (project plan, ConOps, SRS, Architecture Specification, etc.) can be developed in addition to the code artifacts.

Project Ideas:

Workout with Friends:

Fitness challenge app for portable device (phone, android, ipad, etc.). Users can create a circle of friends and compete in fitness activities (e.g., Crossfit challenges combining rowing, pullups, jumps, lifts, etc.). Can choose to compete by absolute score or (preferably) percentage improvements. Members can challenge friends to show they can do what they record (points transfer from loser to winner) or to do specific things. Additional ideas:

• Support for charity challenges
• Team vs. team competitions
• Use data from fitness bracelet (e.g., Ftibit)

Project Team Sorting Hat

Does a better job than the instructor of creating project teams. Students fill out questionnaires on skills and preferences. Instructor defines sorting criteria and constraints (e.g., combining students with common programming language). The system would need to be secure against outside access of student information (quality requirement). Additional ideas:

• Provide multiple input modalities like tablets or phones for questionnaires.
• Support drag-and-drop interface for rearranging teams
• Present several choices optimizing different parameters

Campus Guide

An interactive phone/tablet app helping users find their way around campus. Given current location (or two points) on a campus map, will show the shortest path to get from one to the next. Additional ideas or features:

• Supports self-guided tours. Can download pre-packaged tours as a set of waypoints (string of destinations).
• Event guide: guides user to locations associated with an on-campus events (e.g., homecoming, alumni events, game day)
• Supports short-cuts (e.g. walking through buildings)

Interactive course evaluation data (data scraping)

Course evaluation data for all UO (including CIS) courses since 2007 is available to students through the DuckWeb Course Evaluations page. This app would scrape the Course Evaluation data to provide it in real time to students who are planning which courses to take. For example, presenting the data while the student is browsing the course listings. Additional ideas:

• Rank a set of courses according to evaluation parameters
• Combine with scheduling assistance to rank only courses the student is able to take in the next quarter.