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

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 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 must support importing and exporting a set of addresses to other address books. The import/export format standard 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. It must be possible to extend and update the addressbook design as requirements change.

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 additional email address, mobile phone number, business phone, birthday, etc. .
  2. As the number of entries gets larger, we will want to be able to search the address book.
  3. Ability to keep customized address books with different types of entries in each.
  4. Ability to merge address books.

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 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. 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. The application would run on some combination of the Mac Mini server attached to the display and hand-held devices es.

2. Pilot Training Tool (Customer: Dorothy Schick, TakeWing Aviation)

A visual/graphical (web-based) tracking program that shows student pilots the flight hour progress toward specific FAA license requirements, and graphical visual representations of their skill/grade levels for individual maneuvers or procedures. Progress is tracked vs. calendar time with a date sensitive regression to indicate practice or proficiency has lapsed.

Pilots in training are required to learn both skill-based maneuvers and decision-making. There are specified maneuvers, procedures, decision-making skills, and flight hour requirements. Students progress from basic to more advanced and as the student progresses they must be meet higher and higher requirements and learn new skills (for example, initially holding assigned altitude +200 or - 200 feet transition to better than +/- 100 feet). As in any learning situation, the skill building comes in stages with higher and higher standards of proficiency required as the pilot gains flight time and aptitude. Ideally grading would be in a straight line but unfortunately skills deteriorate or regress with lack of practice and other variables, the biggest variables being time and how often the skill is practiced.

Students and instructors need a graphical portrayal (like a thermometer graph) of which flight requirements have been completed, but they also need to see their flight hours vs. calendar time which would show when a maneuver skill has regressed (or will regress). This would help them identify which maneuvers and procedures they should review and practice when a predicable amount of time has elapsed. For example, a novice student typically looses his/her ability to perform the “Before Takeoff Checklist” at the “intermediate” grade level when they have not practiced it for 10 or more days. Whereas, an intermediate or advanced level student may have that extended to 20-days.

Key program attributes:

2. 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.

I will continue adding to this list as time and opportunity permit.