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:.- Performance: the software should respond to user requests at a speed equal to or better than competing applications.
- Reliability: the system should enter and retrieve or exchange 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 fields (or other) 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
- Add additional fields to the entries: for example, fields for additional email address, mobile phone number, business phone, birthday, etc. .
- As the number of entries gets larger, we will want to be able to search the address book.
- Ability to keep customized address books with different types of entries in each.
- Ability to merge address books.
Subsets and Extensions
- Simpler version with only name and phone number
- Allow user-defined fields
- Support multiple address books with different 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:
- Access the address book using a non-GUI interface (e.g. command line)
- Add addresses
- Retrieve addresses
L1: Version 1
- Simple address book as described in the initial requirements
- GUI for entering accessing address book operations
L2: Version 1.1
- 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. 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:
- Support accounts for individual students allowing updates to student progress and graphically presenting progress on skill sets. Should support secure access by instructor and student.
- Track progress against calendar
- Provide visual warnings for elapsed or nearly-elapsed skills
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.