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 Calendar Application

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 the customer wants, 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 calendar. At a minimum, a calendar holds a collection of events, each recording an event name, date, start time, end time, and description.

Initial Requirements

1. It must be possible to add a new event to the calendar, edit existing events, and delete events.
2. It must be possible to easily see what is on the calendar today. And tomorrow. And the next day.
3. The program should keep track of whether any changes have been made to the calendar since it was last saved, and offer the user the opportunity to save changes when the calendar 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.
4. It is anticipated that the calendar application will be routinely updated to add features, improve capabilities, or improve quality. It must be possible to extend and update the calendar design as requirements change.

Quality Requirements:

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

1. 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.
2. Reliability: The system should enter and retrieve or exchange properly formatted calendar data without loss or error.
3. Standards: The calendar software should ensure that data entered is consistent with HH:MM and DD/MM/YYYY date time standard. Optionally, events might be expected to occur on the quarter hour (such as 1:15PM, 1:30PM, etc.)
4. Consistency: It should be possible to edit the name (or other fields) at any time while keeping the associated data.
5. 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).

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. Notify users of scheduling conflicts and give them options to resolve the conflicts.
2. Allow for adding recurring events (daily, weekly, monthly, yearly)
3. Permit users to define categories for events (such as "work", "home", etc.).
4. Permit users to define priorities for events (such as "high", "medium" , or "low").
5. Permit users to see events based on category and/or priority, such as to easily seewhat are the high priority events today? Tomorrow? The next day? Or, what are the low-priority work-related events today? Tomorrow? The next day?
6. Allow users to change their time zone (and update events accordingly).
7. Allow for multi-day events.
8. Allow for adding all-day events.
9. Set a default day and time for setting an event.
10. Permit two calendars to be merged into one.
11. Permit the user to view events by month.
    

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.

• A bug-free application with reduced capability that is delivered to the market on time is worth more (and will get a better grade) than a buggy or late application with lots of features. All project products should be reviewed against the Project Grading rubric.
• 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.
• Likewise, a design that allows for features to be added easily is superior to one that satisfies initial requirements but is difficult to extend.

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:

• Implement basic interaction with either a text-based or graphical user interface (GUI).
• Add an event to a date and time in the calendar.
• View any day's events.

L1: Basic Address Book

• Save all data to a file, and reload that data every time the program is launched.
• Easily add a new event, edit existing events, and delete an event.
• Easily view what is on the calendar today. And tomorrow. And the next day.
• Work for all days in 2018-2020.

L2: Advanced Address Book

• Support for one or more of the Advanced Features.

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

While working on Project 1, your team should be cultivating ideas for Project 2.

The second project has two objectives:

• Demonstrate your grasp of Software Engineering principles and concepts covered in CIS 422/522
• Develop an open-source quality application on schedule

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:

• 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 developed in 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 in scope that a complete set of development artifacts (project plan, ConOps, SRS, Architecture Specification, etc.) can be developed in addition to the code.

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

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)

Real-time Response System

Being able to get real-time student feedback during class (e.g., answering a posted question) but I've had bd experiences with comercial systems. This project would begin to implement an open-source replacement for an in-class question/response system. While it is likely not possible to implement all of the features of a commerical product, 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.

Project Team Sorting Hat

Feel like you got put in Siytherin but are a Hufflepuff at heart? Now you have a chance to build some software to fix the problem. Application, ideally, will do 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

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 meeting 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). While synching with an app like Google calendar could be effective, a more imaginative approach that removes the complexities of calendar management migt be better.